On the use of observables in concept definitions

echeetham · September 17, 2026, 5:24pm

Dear MAG

An addition to the September 2026 Editorial Guide (‘Findings and Observables’) caught my eye. It states:

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 and here) 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 |Discharge from eye| and 248952001 |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 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. 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 |Histologic type of primary malignant neoplasm of breast| and a value of 863926008 |Angiosarcoma| and another record containing 721576006 |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

jcase · September 29, 2026, 3:25pm

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.

echeetham · September 30, 2026, 2:12pm

Thanks Jim

I appreciate the response and look forward to seeing how the various challenges are dealt with.

I think I’m familiar the background to the removal of “scale type” in observables modelling from item 4 in this 2020 EAG discussion; if this isn’t the same rationale then I’d be interested to hear it. I’m probably biased but I can’t help thinking this says more about problems with the interprets/has_interpretation pattern than it does about the utility of efforts to specify nominal value sets allowable for observables. I also note that scale type modelling lives on in a number of established IE observables: for example, 78564009 |Pulse rate| and 75367002 |Blood pressure| are both modelled with 370132008|Scale type|=30766002|Quantitative value| (suggesting they are designed to take numeric values) but are then used in the definitions of findings assigned qualitative/nominal has_interpretation value such as 281302008|Above reference range| and 263654008|Abnormal|.

jcase · September 30, 2026, 3:30pm

Ed,

The rationale in the 2020 EAG discussion is the one to which I was referring. I recognize that it also raises a broader question about the INTERPRETS/HAS INTERPRETATION modeling pattern.

I do not, however, see an inherent inconsistency in using a quantitative observable such as |Pulse rate| or |Blood pressure| to define a finding with a qualitative interpretation such as |Above reference range| or |Abnormal|. The scale type characterizes the type of value produced by observing or measuring the property, whereas HAS INTERPRETATION represents the judgment applied to the result.

This is analogous, although not identical, to the representation in HL7 version 2. OBX-3 identifies the observation, OBX-5 carries the observed value—often a quantitative measurement—and OBX-8 carries a categorical interpretation of that value, such as high, low or abnormal. A numeric blood-pressure result can therefore be accompanied by the interpretation “above reference range” without changing the quantitative nature of the underlying observable.

In the SNOMED CT Clinical finding model, INTERPRETS identifies the observable being interpreted and HAS INTERPRETATION represents the qualitative judgment. Representing quantitative values directly in the definitions of Clinical findings would be of questionable usefulness, particularly because the clinical significance of a measurement may depend on reference ranges, patient context and measurement method. Consequently, the Clinical finding MRCM does not provide an attribute that permits concrete values to be used in this modeling pattern. HAS INTERPRETATION therefore provides a mechanism for defining a clinically useful qualitative finding without incorporating the actual measured value into the concept definition.

This does not resolve your broader concern about how the permitted nominal interpretations for a particular observable should be constrained. I agree that clearer guidance is still needed on that point.

gbyrn · October 1, 2026, 11:42am

Thanks both,

this thread is of particular interest as I work in the realm of structured assessment; implementing FHIR/SNOMED for pathology & lab medicine reporting. In this use-case, the OE asks the question, ‘what is the result of X lab test?’, with the associated value + interpretation providing the answer. It’s a straightforward model of meaning, but our implementation still requires a conservative approach because of the complexities involved, & I agree with Ed’s concern that OEs created solely to support modelling of clinical findings could muddy the waters around how systems interpret the clinical information conveyed.

E.g., when a clinician asks, ‘what is the result of a mass concentration of troponin T in serum test?’ & the answer comes back ‘1,000+ ng/L / very high’, it strongly suggests the patient’s had a heart attack, but it’s not definitive. Consequently, Myocardial infarction (disorder) doesn’t use Interprets / Has interpretation & the boundaries are clear. On the other hand, genetic tests, MC&S, & tissue biopsies can definitively diagnose disease. However, if OEs representing these tests were used in the modelling of related clinical findings, systems could infer that the lab test had been performed, when it may not have been, which speaks to Ed’s point that ‘No explicit ‘question’ may have been asked and no separate ‘answer’ given.’

As this discussion also touches upon, structured assessment gets more complex when the measurable characteristic of a lab test is qualitative & the result is presented as narrative text.

That said, here in England we’ve been able to tie the rules down around OEs, values, interpretations, & their modelling in the relatively straightforward world of ‘traditional’ blood sciences, especially as our FHIR-based Spec. controls the information model. How OEs are implemented beyond such a tight scope without introducing duplication, redundancy, or muddled meaning is more problematic however, so I’d welcome clearer guidance.
Cheers,
Gogs Byrn