1. Observable entities and Clinical findings
Some thoughts for group discussion…
David Sperzel
July 2017

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

3. 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 ).

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

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

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

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

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

9. Why might the value of a feature of one entity need 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.

10. 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…

11. 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
Sidebar: When should observation procedures be named to facilitate reuse (as opposed to repeating the same set of observation procedure attributes in multiple observable entity concepts)?

12. 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.)

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

14. 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 | Is about (attribute) | attribute with the range extended to include | Clinical findings | and | 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.
We may not need a different model.
We may just need better words!

15. Consider the word “status” and how it is currently used in SNOMED CT
Searching for “status” in the January 2017 edition returns 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)

16. Could using the word status in PROPERTY TYPE values help solve some of our problems?
”Status” appears to be a reasonable way to describe:
A feature that INHERES IN an independent continuant
A feature that CHARACTERIZES a process
Consider using a status property type and appropriate subtypes to address the “problem of presence.”
Status (property) (qualifier value) in Status observable (observable entity)
Presence-absence status (property) (qualifier value) in Presence-absence status observable (observable entity)
Suggestion: Using the word “status” in this way could arguably remove (or greatly reduce) the aforementioned conflict between the existential restriction used in SNOMED CT definitions and the use of the word “Presence” as a PROPERTY TYPE value.

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

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

19. Suggested modeling options: WHERE SHOULD WE PUT OBSERVATION RESULTS?
A separate observation result hierarchy
Findings as observation results
Expanding the existing Clinical finding hierarchy
Suggested modeling options: WHERE SHOULD WE PUT OBSERVATION RESULTS?

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

21. 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| = |Lesion (morphologic abnormality)|,
|inherent location| = |Retinal structure (body structure)|,
|using device| = |Ophthalmoscope (physical object)|
Dot-blot hemorrhage present (observation result)
|Observation result|:
|is about / refers to / has observation context| =
|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)

22. 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)

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

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

25. 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)

26. 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.”

27. 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
ASSOCIATED MORPHOLOGY
ASSOCIATED WITH
DUE TO
CAUSATIVE AGENT
BEFORE
DURING
AFTER
CLINICAL COURSE
EPISODICITY
FINDING SITE
OCCURRENCE
PATHOLOGICAL PROCESS
SEVERITY
Observation result attribute set
INTERPRETS
HAS INTERPRETATION/ HAS VALUE / HAS RESULT
FINDING INFORMER
FINDING METHOD
Context attribute set
SUBJECT RELATIONSHIP CONTEXT
TEMPORAL CONTEXT

28. Explicit observation result
Option 3: Clinical findings and explicit vs. implicit observation results (1)
Clinical finding
Clinical life phase
Explicit observation result
A clinical finding can be regarded as either a clinical life phase (which has a default context) or an explicit observation result (which has a specified result and/or context).
This distinction could be represented directly in the hierarchy or it could merely be implied by which attribute sets are used (just as the use of different sets of attributes in the Observables model provides a distinction between the target of an observation and how the observation is made).

29. 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
|Retinal dot hemorrhage (finding)|
Most proximal primitive (in this case)
|Clinical finding|:
{ |associated morphology| = |Hemorrhage (morphologic abnormality)|,
|finding site| = |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| = |Subject of record (person)|,
|temporal context| = |Current or specified time (qualifier value)|
The last four attributes show how the default context could potentially be made explicit for clinical findings

30. Explicit observation result
Option 3: Clinical findings and explicit vs. implicit observation results (2)
Clinical finding
Clinical life phase
Explicit observation result
No changes to current definition of clinical life phase
No changes to current rules for default contexts. When the code for a clinical finding or procedure is used in a medical record, it becomes an implicit observation result because it has a default context.

31. Explicit observation result
Option 3: Clinical findings and explicit vs. implicit observation results (3)
Clinical finding
Clinical life phase
Explicit observation result
An explicit observation result should be represented in SNOMED CT only when there is a need to distinguish it from the implicit observation result represented by the default context.

32. Explicit observation result
Option 3: Clinical findings and explicit vs. implicit observation results (4)
Clinical finding
Clinical life phase
Explicit observation result
An explicit observation result
MUST have a VALUE (a.k.a. INTERPRETATION) that differs from the default.
MUST INTERPRET an observable entity.
MAY have a SUBJECT RELTIONSHIP CONTEXT that differs from the default.
MAY have a TEMPORAL CONTEXT that differs from the default.

33. Explicit observation result
Option 3: Clinical findings and explicit vs. implicit observation results (5)
Clinical finding
Clinical life phase
Explicit observation result
If an explicit observation result is about a procedure or event, it can use the (temporal) BEFORE, DURING, or AFTER relationships to refer to the procedure or event.

34. Option 3: Pros and cons Pros Con
No new or renamed hierarchies are required.
No changes to rules for default contexts.
Con
Reduced ontological clarity because information entities (observation results) and the clinical entities that they “are about” reside in the same hierarchy – but the SDP model already puts structures (material entities), dispositions (dependent continuants), and processes (occurrents) in the same hierarchy.

35. Final 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
Final questions and summary of suggestions

36. Questions and suggestions (1)
Question: How important is a strict distinction 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?

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

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

39. Questions and suggestions (4)
Suggestion: In addition to providing a value for the feature represented by an observable entity, an observation result may need to refer to a different entity that provides additional context for the observation.
This could be accomplished with an additional REFERS TO / HAS OBSERVATION CONTEXT attribute, or the “about-ness” of an explicit observation result could be implied by the use of existing Clinical finding attributes.

40. 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 explicit observation result
Must INTERPRET an observable entity
Must have a value (as specified by a HAS INTERPRETATION / HAS VALUE / HAS RESULT attribute).
May have additional context:
SUBJECT RELATIONSHIP CONTEXT
TEMPORAL CONTEXT
(Possibly) IS ABOUT / REFERS TO / HAS OBSERVATION CONTEXT

41. Questions and suggestions (6)
Suggestion: 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).
Suggestion/Conclusion: Option 3 appears to be the best approach because it would not require creation of any new top- level hierarchies.