Observable Entity vs. Evaluation Procedure — Background and Discussion

SNOMED Groups Editorial AG
,
1

The attached document provides a structured background on the long-standing question of whether SNOMED CT should maintain separate Observable entity and Evaluation procedure hierarchies for laboratory and clinical observations, or consolidate to a single Observable entity hierarchy. It covers the historical context from the E2O project through the 2023 SMT decision and the August 2025 policy revision proposal, the scope of affected content, the member country landscape, and a structured analysis of the arguments for and against each approach. Method and technique concepts (e.g., ELISA, PCR) are explicitly out of scope for this discussion.

The document is intended to support an informed community discussion rather than to present a final position.

Key question for the community:
Does the SNOMED community support consolidation to a single Observable entity hierarchy for laboratory and clinical observations, or is continued maintenance of a separate Evaluation procedure hierarchy required to meet member implementation needs?

Expected outcomes:

  • A clear signal of community position on the one- vs. two-hierarchy question, with the reasoning behind it

  • Where support for two hierarchies is expressed, identification of the specific implementation dependencies that require it and what conditions would need to be met for those dependencies to be resolved

  • Input on whether laboratory and clinical observation evaluation procedures warrant different treatment, given the relative maturity of LOINC extension coverage in the laboratory domain

  • A clearer picture of member appetite for a transition plan, and what conditions — particularly around LOINC extension maturity and national implementation timelines — would need to be in place for one to be viable

    Observable_Entity_vs_Evaluation_Procedure_Synthesis_v2.pdf (278.8 KB)

2

I would support consolidation to a single Observable entity hierarchy, at the very least for laboratory observations. The current division across different hierarchies blocks any solution for connecting orders and observations through subsumption.

The Netherlands has not yet chosen a preferred terminology for ordering lab tests. The laboratories would prefer LOINC, but LOINC so far has been too detailed for the hospitals and GPs. Regenstrief is busy solving that problem by creating {Measurement} codes for ordering. But if the SNOMED core keeps orders in the evaluation procedure hierarchy and the LOINC extension puts them in the observable entities, the terminological confusion just grows.

A transition plan for those countries that currently use separate hierarchies or terminologies would, I think, help to determine what conditions must be met before the hierarchies can be merged.

3

Hi @fhielkema;

Do you have any thoughts about adding possibly one or two new semantic tags to the observable entity hierarchy to better clarify the intent of a single hierarchy solution?

Having an “observation order” semantic tag would help to differentiate the intent of the observable entity concept from that of an “observation entity” concept that represents either a quantitative or qualitive result value from an implementation perspective.

The semantic tag of “Observation order” may also provide an indicator that additional input parameters (i.e. observable entity concepts) may be associated with the concept that represent “ask at order entry” questions.

The business logic from the clinical findings hierarchy that prevents a “disorder” concept from becoming a parent of a “finding” concept could be applied to the observable entity hierarchy to prevent an “observable entity” from being modeled as a parent of an “observable order”.

Attempting to think through the required elements that we would need to put into place to ensure the proper implementation of a single hierarchy solution of the terminology.

4

@jsnyder If we were to do that, we would need three additional semantic tags (remeber not all observables are laboratory). They would need to include the order only, order/obs, and obs only flavors. An observable entity “should” never classify as a parent to an order only code for a couple of reasons: 1) order are modeled much less completely as observalbles (that conform to the LOINC pattern) a 2) other potential erroneous parents are already unmodeled so would need to be manually assigned as parents to order onyl codes, which i doubt would happen.

The single hierarchy “solution” has already been implemented by people that use LOINC (e,g, panels), so really the issue would remain about the proper mapping of local codes to the optimal Observable instead of picking the first one you see.

5

Agreed. It’s tempting to add a new semantic tag to distinguish orders from observations, but I can’t work out how that would be done without hindering subsumption and/or causing unnecessary duplication. In effect, the same arguments apply against it as for maintaining two separate subhierarchies.

6

As a holding position and in case silence were to be mistaken for assent or indifference … I oppose the consolidation. A detailed response will follow in due course.

3 Likes
7

I sit firmly in the two-hierarchy camp described in 2.3, and apologies for the length post but I wanted to ensure my rationale was clearly laid out in a single post.

An observable entity is an inherent property of something that can be observed, whether or not anyone measures it. An evaluation procedure is the activity of evaluating that property. The observation is the result. An infant has a weight whether or not we weigh them; weighing the infant is a procedure; “4.1 kg” is the observation. These are three different things, and the difference is not one of phrasing.

The premise does not survive contact with the current content. The document’s core claim is that evaluation procedures are empty, unmodelled placeholders that are “for all intents and purposes, observables with a different semantic tag.” That is not what the edition shows. Take the poster-child pair:

  • 33747003 |Glucose measurement, blood| is sufficiently defined, with Method = 129266000 |Measurement - action| and a blood specimen. It is modelled as an act.
  • 434912009 |Blood glucose concentration| is primitive, with no attributes at all.

Even here the two are not interchangeable. The procedure carries the specimen and the measurement action; the observable is a bare property. They resemble each other because this domain has sat in editorial hiatus for the best part of a decade, not because they are the same kind of thing.

At scale, the “under-modelled procedures” claim is actually reversed. <122869004 |Measurement procedure| is roughly 57% sufficiently defined (4,362 of 7,695); <363787002 |Observable entity| is roughly 15% (1,694 of 11,158). @jcase, your point above that order concepts are modelled much less completely than observables is the opposite of what I find. If either hierarchy is the primitive, under-specified one, it is observables, which I would put down to LOINC owning the result space (OBX-3) for decades rather than any defect in the procedure model.

Look-alike is not the same. Much of the case for one hierarchy rests on the two containing near-identical pairs. But SNOMED deliberately maintains near-homonym concepts across hierarchies all the time, because they are different kinds:

  • 429040005 |Ulcer (disorder)| and 56208002 |Ulcer (morphologic abnormality)|
  • 425558002 |Azoospermia disorder (disorder)| and 48188009 |Azoospermia (finding)|
  • 78014005 |Urine (substance)| and 122575003 |Urine specimen (specimen)|
  • 387207008 |Ibuprofen (substance)| and 38268001 |Product containing ibuprofen (medicinal product)|, which share the same preferred term in the AU edition

Nobody proposes merging morphologies into clinical findings because they carry the same term. The same reasoning applies to observable and evaluation procedure.

The subsumption argument is the one that sounds strongest, but it conflates a modelling problem with a structural one, and it does not require a single hierarchy. If you want every glucose observation, that is a query within the observable hierarchy: a grouper concept, or ECL over the component, <363787002 |Observable entity| : 246093002 |Component| = 67079006 |Glucose|. That query is thin today, three concepts, only because the observable hierarchy is barely modelled, not because the procedures are in the way; the same query against the procedure hierarchy returns 88. So the difficulty is modelling maturity, and merging the two would not fix it, because you would still have to populate the same attributes to make the query work.

If you want observations and requests together, that is inherently a two-field question: the request sits in OBR-4 or ServiceRequest.code, the result in OBX-3 or Observation.code. You are already reading two fields, so matching each with its appropriate hierarchy is the natural fit rather than an overhead, and where legacy records have placed procedure codes in the result field the query can simply include both. That is a data-quality artefact, not a reason to restructure the terminology. On core versus extension, I agree that core keeping orders in evaluation procedure while the LOINC extension places results in observable is confusing, but the fix is clear guidance on which code belongs in which field, not collapsing the hierarchies.

The tag proposals make my point for me. Introducing an “observation order” tag, or the three tags Jim describes (order-only, observation-only, and a third for the overlap), is an admission that these are two different kinds of concept. It just re-encodes that distinction lexically inside a single hierarchy, with an extra tag for the grey zone, instead of using the hierarchy split that already carries it. And a semantic tag is the weaker mechanism: it labels but does not classify, so the reasoner cannot act on it, whereas it can act on two hierarchies. John’s own rule, that an observable must never parent an observation order, concedes the same point.

The single-hierarchy story only looks plausible for atomic analytes, and falls apart the moment you leave them. None of these are observables by any reading:

  • 168132005 |Microscopy, culture and sensitivities|
  • 7246002 |Kidney biopsy|, where the request describes specimen collection and the expectation of some sort of pathology investigation is implied.
  • 168821007 |Barium swallow|, 303653007 |CT of head|, 426420006 |Plain X-ray of left ankle|
  • 373620007 |Romberg test|, 408589008 |Falls assessment|, 425315000 |Cardiac assessment|

The order and the result also occupy different fields in the exchange standards, for different objects:

  • the ORDER code in the request (FHIR ServiceRequest.code, v2 OBR-4)
  • the RESULT code in the observation (Observation.code, OBX-3)

A single hierarchy can look acceptable while the mapping stays a simple one to one, where the same concept might plausibly serve both the order and the result:

Order: 104934005 |Sodium measurement, serum (procedure)|
Result: 2951-2 |Sodium [Moles/volume] in Serum or Plasma|

Order: 271062006 |Fasting blood glucose measurement (procedure)|
Result: 14771-0 |Fasting glucose [Moles/volume] in Serum or Plasma|

But orders are not one to one with observations, so “two temporal states of the same thing” (6.2.1) does not hold:

Order: 20109005 |Electrolytes measurement, serum (procedure)| Result:

  • 2951-2 |Sodium [Moles/volume] in Serum or Plasma|
  • 2823-3 |Potassium [Moles/volume] in Serum or Plasma|
  • 2075-0 |Chloride [Moles/volume] in Serum or Plasma|

How would a sodium observable relate to an electrolytes panel in a single hierarchy?
The same sodium observation applies to the panel, or as a single test.

Order: 113076002 |Glucose tolerance test (procedure)| Result:

  • 14771-0 |Fasting glucose [Moles/volume] in Serum or Plasma|
  • 51597-3 |Glucose [Moles/volume] in Serum or Plasma --1 hour post 75 g glucose PO|
  • 14995-5 |Glucose [Moles/volume] in Serum or Plasma --2 hours post 75 g glucose PO|

And how would a fasting glucose observable relate to a glucose tolerance test, or to the other panels that also report it? Again, the fasting observable is agnostic of what test it is a part of.

Some association between order and result helps implementations with request and result reconciliation, but it does not need to live in the terminology, and it is not always a clean one to one mapping. Reflex and add-on testing makes this worse, for example a creatinine run alongside a urine albumin to judge specimen dilution that was not explicitly ordered.

This is also why the Interprets range needs both hierarchies, and why I would not tie it to one. 75183008 |Abnormal liver function| interprets 79036002 |Liver function (observable entity)|, an inherent property. But 168943003 |Abdominal aortography abnormal| interprets an angiography procedure (Method = 360037004 |Imaging - action|), and 168628003 |Plain X-ray of ulna normal| interprets a plain X-ray procedure. There is no aortography observable to interpret; what is interpreted is the act. Merge everything into observables and you can no longer state correctly that an X-ray-normal finding interprets an X-ray.

None of this defends the current state of the evaluation procedure hierarchy. It needs a proper clean-up, including reducing genuine overlap with observables. But that overlap is largely an artefact of the domain being parked for a decade during the LOINC discussions, together with the more recent addition of less specific observable groupers as part of the LOINC ontology work. Content created to fill a gap should not then be cited as evidence that the gap proves duplication. The answer to a neglected hierarchy is to maintain it, not to declare it redundant.

On duplication, there should be no expectation that every observable gain a procedure twin. The two hierarchies fill by different criteria: an evaluation procedure earns its place by being something people actually order, while laboratory observable content is effectively gated on LOINC coverage. They diverge more than they duplicate. New evaluation procedures should be added only where there is a real request for one, and legacy procedures that are never ordered are precisely the clean-up candidates. That is content curation, not an argument for one hierarchy.

It is worth being clear about what the case for a single hierarchy rests on. The recurring arguments, less duplication, less maintenance, closer alignment with LOINC tooling, are about convenience, and those are real operational goods. But convenience is not evidence that an order and an observation are the same kind of thing, and the kinds are what a terminology should get right.

So my position is the two-hierarchy model, retained and cleaned up, applied consistently across all domains rather than split into laboratory and clinical. (Two smaller notes. The laboratory-versus-clinical split in section 3 looks to me like an arbitrary distinction (based on convenience) rather than a real boundary: 430327009 |Colour of urine| can be read at the bedside or in a laboratory. And I would leave panel contents undefined, since they vary by jurisdiction and reimbursement and we cannot agree on them even within Australia. Happy to provide more examples if required.

4 Likes
8

I’ve very little to add to this on top of Matt’s response (agree) and Jeremy’s (due to follow) except that I can’t help but notice that the discussion very quickly turned to creating ‘semantic tags’!

9

Great discussion. I would also like to bring into consideration an idea that has come up in previous meetings and may be relevant across the different options being discussed.

This is the possibility of introducing a new attribute to explicitly link an evaluation procedure to the observable entity it evaluates.

Under this approach, an evaluation procedure would evaluate or observe an observable entity. The defining attributes that describe what is being measured or assessed, such as component, property, time aspect, scale type, and related characteristics, would be modeled only on the observable entity.

The evaluation procedure would then carry the attributes that describe the nature of the procedure itself, such as method, priority, access, device, or other procedural characteristics.

For example:

Blood glucose concentration (observable entity)

  • Component = Glucose
  • Property = Substance concentration
  • Inheres in = Blood

Blood glucose measurement (procedure)

  • Method = Measurement action
  • Evaluates = Blood glucose concentration

This would preserve the ontological distinction between a property that can be observed and the activity performed to evaluate it, while avoiding duplication of the same defining model across both hierarchies.

Of course, this would require further discussion regarding cardinality, panels, procedures that may evaluate multiple observables, and cases where no observable can be identified. However, for atomic evaluation procedures, it could provide a cleaner separation between the semantics of what is measured and the semantics of how the evaluation is performed.

1 Like