# On the use of observables in concept definitions

**URL:** <https://forums.snomed.org/t/on-the-use-of-observables-in-concept-definitions/1608>\
**Category:** Modeling Advisory Group\
**Tags:** discussion\
**Created:** [September 17, 2026, 5:24pm UTC](https://forums.snomed.org/t/on-the-use-of-observables-in-concept-definitions/1608 "2026-09-17T17:24:40Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![echeetham](https://avatars.discourse-cdn.com/v4/letter/e/c0e974/32.png) [@echeetham](https://forums.snomed.org/u/echeetham)\
**Post date:** [September 17, 2026, 5:24pm UTC](https://forums.snomed.org/t/on-the-use-of-observables-in-concept-definitions/1608/1 "2026-09-17T17:24:40Z")

</div>

Dear MAG

An addition to the September 2026 Editorial Guide (‘[Findings and Observables](https://docs.snomed.org/snomed-ct-specifications/snomed-ct-editorial-guide/readme/authoring/domain-specific-modeling/clinical-finding-and-disorder#findings-and-observables)’) caught my eye. It states:

_“The term observations should not be confused with Observable entity. Observable entity is the name of something that can be observed and represents a question or assessment (e.g. |systolic blood pressure|, |color of iris|, |gender|) which can produce an answer or result._

_Given differences in information models, a finding about the subject of the record may be captured in different ways. For example, the information may be captured using either an Observable entity concept together with a value, or a Clinical finding concept which represents what is being observed together with the result of the observation. To assist the transformation between these concepts, **if when adding a requested Clinical finding concept, the modeling requires an Interprets relationship, and the Observable entity concept does not exist, then a new Observable entity concept should be created.** ”_

I understand the practical motivation behind this guidance, but I think it exposes a longstanding modelling problem (and fundamental concept representation problem) that deserves further explanation before creating additional content in line with this guidance clause becomes routine. This is a topic on which I have written before (e.g. [here](https://conf.spaces.snomed.org/wiki/spaces/editorialag/pages/134002822/2016-08-22+Editorial+Advisory+Group+Conference+Call?focusedCommentId=134002920) and [here](https://forums.snomed.org/t/changes-to-obesity-and-central-obesity/1028/2)) but am yet to receive a convincing or reassuring answer.

For observations associated with ratio or interval quantities, the ‘Observable + value’ pattern is generally justified and understandable. An observable such as mass concentration of sodium in serum includes a recognisable property, and there is a reasonably clear and reproducible boundary between the observable and the value/result such as 140 mmol/L.

The position is much less clear where the finding takes a nominal value, a situation made more complex (a) where the created observable has no readily understandable property type and (b) where the same ideas are handled differently in SNOMED’s formalism.

**What does the new observable represent?**

The part of the new guidance that concerns me most is:

_ **“…then a new Observable entity concept should be created.”** _

What rules determine the nature of that observable? In particular:

- Should it include reference to a recognised property type (and if not, what then is being ‘observed’)?
- Should its expected value datatype or permitted value set be declared (see below)?
- What governs the allocation of semantics between the observable and its value?
- What evidence demonstrates that independent authors would create the same observable for the same purpose?
- How should its equivalence with the corresponding Clinical finding be established (and/or what does the vague _“…assist the transformation between the concepts…”_ mean in practice)?

Without answers to these questions, the new guidance appears to permit almost anything that can be framed as a question to be reverse-engineered into an Observable entity.

The existing Interprets/Has interpretation mechanism provides only partial support here. A Clinical finding may be defined in terms of an ‘Observable + value’, but nothing guides whether the selected partition is appropriate or reproducible. The value set for Has interpretation has grown considerably in recent years (a near 20x increase from 2021 (200) to 2026 (3800)) but still there are no visible rules for determining the values suitable for specific Observables or corresponding property types. The problem is compounded further where semantically proximate findings use different modelling patterns, such as Finding site/Associated morphology (compare, for example, the modelling approaches to [246679005](https://snomedbrowser.org/?perspective=full&conceptId1=246679005&edition=MAIN&release=&languages=en) |Discharge from eye| and [248952001](https://snomedbrowser.org/?perspective=full&conceptId1=248952001&edition=MAIN&release=&languages=en) |Discharge from female genitalia|, the latter defined using an observable added in September 2026).

**Models of capture are not necessarily models of meaning**

There is also a broader issue arising from the increasing use of an ‘Observable + value’ content defining pattern.

A structured assessment _is_ a legitimate model of capture – I understand and support such an approach if done well (see policy statement 4 [here](https://www.acpjournals.org/doi/10.7326/M14-2128?url_ver=Z39.88-2003&rfr_id=ori:rid:crossref.org&rfr_dat=cr_pub%20%200pubmed) for an ACP position on structured recording). Where a recognised instrument asks a defined question, constrains its permitted answers and records the relevant context, an ‘Observable + value’ recording structure accurately preserves both how the information was elicited and the resultant semantics.

However, it does not follow that the ‘question + answer’ structure should automatically become the canonical model of meaning (as will be the case for many SNOMED CT Findings defined using the Interprets/Has interpretation modelling pattern).

Clinical records will also contain direct, nominalised assertions (as Findings). A clinician may record that a patient has green eyes, is at high risk of suicide or has a discharge from a particular part of their body. No explicit ‘question’ may have been asked and no separate ‘answer’ given.

These two (incompletely comparable) patterns will become increasingly relevant to the coding steps used with ambient voice technology and other AI-assisted documentation. A system receiving a narrative statement may suggest codes based on:

- mapping it to a Clinical finding representing the assertion; or
- decomposing it into an Observable entity and nominal value.

Where the (latter) decomposition is not governed by reproducible rules, different systems may make different (and analytically consequential) choices. Editorial variability will then begin to appear in clinical coding workflows, with the clinician author or coding algorithm arbitrarily deciding where the observable/value boundary should lie.

The code suggestion workflow may also add a potential review burden/friction. A clinician may be expected to review a suggested code for ‘green eyes’ to assess whether it reflects what was said during the encounter, before committing it to the record. Reviewing multiple codes presented as ‘eye colour’ (or ‘iris colour’) plus a ‘green’ value requires the clinician to validate a decomposition presented as a ‘question that was never asked’ and an ‘answer that was never given’. This may be structurally elegant, but it is not necessarily the most transparent representation of the source assertion.

**Additional points**

A similar sentiment to the ‘Findings and Observables’ section above is made in the [Cancer Synoptic Reporting Implementation Guide](https://docs.snomed.org/implementation-guides/cancer-synoptic-reporting-implementation-guide/3-snomed-ct-content/3.2-observable-entityobservation-pairs-versus-clinical-findings). This section helpfully describes the sorts of content that would be needed to serve as ‘answers’ to the synoptic report questions _(“…values from the Procedure hierarchy, Body structure hierarchy, and concepts in the qualifier hierarchy NOT subsumed by \<\< 260245000 |Finding value (qualifier value)|…”)_. The use of such values in record instances will likely introduce even more opportunity for the same clinical ideas to be represented in non-isomorphic (and thus analytically remote) ways (consider, for example, one record containing [1660001000004100](https://snomedbrowser.org/?perspective=full&conceptId1=1660001000004100&edition=MAIN&release=&languages=en)|Histologic type of primary malignant neoplasm of breast| and a value of [863926008](https://snomedbrowser.org/?perspective=full&conceptId1=863926008&edition=MAIN&release=&languages=en)|Angiosarcoma| and another record containing [721576006](https://snomedbrowser.org/?perspective=full&conceptId1=721576006&edition=MAIN&release=&languages=en)|Primary angiosarcoma of breast|. I’m not saying they _couldn’t_ both be detected, but…).

**Conclusion**

To me the implication of both these guidance document sections is that SNOMED CT now explicitly supports - by design - incompletely constrained and logically incomparable mechanisms for recording data items that are _intended to mean the same thing_ (at odds with Cimino’s non-redundancy desideratum). The documentation is welcome, the implications are concerning.

Such an approach _may_ be a necessary compromise in order to meet multiple use cases. However, if the SNOMED community wishes to continue down this route then my suggestions would be:

- Content created using an ‘Observable + value’ definition pattern needs to be managed with more care to limit variation - in particular in the design and selection of suitable ‘observables’, and with consistent application of modelling patterns to semantically proximate content.
- The user community - operating at all points in the data lifecycle - needs to be fully aware of this design philosophy and the risks that exist where such an approach is used
- The consequences and risks of this approach need to be explicitly managed to minimise the likelihood of, for example, false negatives in data retrieval and arbitrary patterns of code suggestion in NLP and AI-based coding workflows

I would welcome the MAG’s thoughts.

Kind regards

Ed

---

<div class="post-metadata">

**Author:** ![jcase](https://avatars.discourse-cdn.com/v4/letter/j/57b2e6/32.png) [@jcase](https://forums.snomed.org/u/jcase)\
**Post date:** [September 29, 2026, 3:25pm UTC](https://forums.snomed.org/t/on-the-use-of-observables-in-concept-definitions/1608/2 "2026-09-29T15:25:40Z")

</div>

Ed,

Thank you for this detailed and thoughtful comment. You’ve identified real gaps, and I agree with the core of your concern.

First, there is currently no clear, reproducible guidance on the boundary between an Observable entity and its value, particularly for nominal values. How much meaning belongs in the observable and how much in the value is a longstanding, unresolved question and often is based on the specific use case. Taken to one extreme, any finding can be recast as an observable with a present/absent answer, which would produce an unbounded set of observables that add little beyond the findings themselves.

Second, the new Editorial Guide text overstates the case. As written, it implies an Observable entity should be created whenever a requested Clinical finding “requires” an Interprets relationship. However, the criteria that determine when a finding requires an Interprets relationship have not been clearly defined. Without them, observables may be created to satisfy modeling or classification needs rather than to represent something genuinely observable. Your example of 248952001 |Discharge from female genitalia| is a fair illustration. These criteria need to be developed and will be investigated further.

Third, we agree that any Observable entity that is created should make explicit what is being observed. The Editorial Guide recognises four general types of observables: qualities, dispositions, functions and processes. For quality observables, the property should be stated, such as color, odor, quantity or consistency. For process observables, the process being characterized should be stated, such as secretion rate or heart rate. The same applies to dispositions and functions. This makes clear what is being assessed and what kind of value is expected. Where no such property, process, disposition or function can be identified, an observable is probably not the right representation, and the finding should be modeled directly, for example with Finding site and Associated morphology.

Your broader points also deserve a response. SNOMED CT does support both pre-coordinated findings and observable-plus-value representations. We agree that a question-and-answer structure is a valid model of capture but should not automatically become the model of meaning. The Cancer Synoptic Reporting Implementation Guide is a case where this distinction is deliberate. Its observables were created to support capture in synoptic pathology reports, while neoplastic disorders continue to be defined by finding site and morphology. The two are not intended to be isomorphic, because they serve different contexts of use. It is fair to note, however, that records using either form will coexist, and implementers need to understand this when querying across them. Outside such purpose-built contexts, we agree that inconsistent use of the two patterns creates risks for retrieval and for NLP and AI-assisted coding, and these risks should be made explicit rather than left implicit.

You also asked whether an observable’s expected values should be declared. SNOMED CT does not currently have a mechanism to declare the permitted value set for an individual observable. The scale attribute provides a partial constraint in some cases, but it is currently deprecated (I can provide the rationale if you would like). Reproducibility therefore depends mainly on editorial guidance. Clearer guidance on when an observable is appropriate, and on stating the property, process, disposition or function it represents, would reduce variation, though some variability in modeling approaches exists even under current guidance and is unlikely to be eliminated entirely. One of the objectives of the prior quality improvement project was to identify this variability and document remediation as part of the editorial guidance.

Thank you again for raising these issues.