20260506 BN Measurement Property v1.0

Briefing Note Purpose

The purpose of this briefing note is to inform the community of a proposal to promote 685451010000100 |Measurement property (qualifier value)| from the LOINC Extension to the International Release (IR). The subtype-supertype relationships of this concept in the LOINC Extension will also be promoted to the IR, e.g., 118594004 |Quantity concentration (property) (qualifier value)| Is a 685451010000100 |Measurement property (qualifier value)|. Some updates to the modeling of observable entity content is expected.

Date created 05 May 2026
Action For Information Only
Status Open

20260506 BN Measurement Property v1.0.pdf (125.1 KB)

2 Likes

Thanks.

Given its ‘for information only’ status this briefing note is presumably not intended to provoke further discussion, but I am genuinely curious to understand the reasoning behind this point:

Issue 2 states: “…There are properties which some users may consider to be measurement properties which are not subtypes of 685451010000100 |Measurement property (qualifier value)|, e.g., 705057003 |Presence (property) (qualifier value)|, 118584009 |Presence or identity (property) (qualifier value)|…”

When compared with other << 118598001 | Property | values, “Presence” is, in the eyes of some of us, not strictly a property type at all. The majority of property and quality types are “attribute an object has” such as colour, height or mass (and it is a given that the object already exists to bear this property). “Presence”, on the other hand, can be seen as a “precondition for having any properties at all” and therefore a very different category of thing.

The wording of Issue 2 suggests that not only is presence an unquestionable ‘property type’, but furthermore there are users who feel it also passes more stringent tests for being a ‘measurement property type’ - a property dimension along which variation is quantitative or at least scalar - admitting magnitude, units, and ordered comparison. I would be fascinated to understand this argument.

I’m not going to waste time trying to challenge the use of ‘presence’ as a ‘property type’ (that ship has sailed) but I would seriously argue that ‘measurement property types’ should be restricted to scalar or ordered attributes (mass, concentration, activity, etc.) and ‘presence’/‘presence or identity’ property types should be explicitly called out as exceptions.

Ed

Greetings,

In general, I think the BN and promotion of the measurement properties to the international edition makes sense. Assigning the additional IS A parent of Measurement Property to existing concepts in the international edition should help to avoid or resolve any classification issues, especially at the extension level.

If I am reading the BN correctly, Issue 2 is identifying concepts that are outside the scope of the work and will not be promoted to the international edition. Once the initial set of concepts is promoted and parentage issues resolved, then additional impact analysis can be performed to determine if the promotion of concepts like "PRID (Presence or Identity) to the international edition is warranted. (i.e. let’s cross that bridge when we get to it.)

Discussions about the definitions that LOINC assigned to a given term (e.g. PRID (Presence or Identity)) may be better addressed via the LOINC forum or LOINC laboratory committee. I am not certain any discussions that take place on the SNOMED forum will result in actionable items by the LOINC team.

Thanks John

I’d argue that understanding the background to ‘Issue 2’ (as written) is a SNOMED concern. I have no influence over LOINC and the use of ‘presence’ and its variants is already widespread in both products (and a reasonable, pragmatic solution to the requirements it meets when properly used).

However in a document published in a SNOMED context the briefing note states that “…some users may consider705057003 |Presence (property) (qualifier value)|to be a 'measurement propert[y]”. All I am trying to do is understand the reasoning behind this statement, better understand what ‘measurement properties’ are and thus, hopefully, how to distinguish them from the set of ‘non-measurement properties’.

As it happens 705057003 |Presence | is, by some distance, the most used property type in the SNOMED International Edition. Currently only ~2000 (of 11000) IE observable entities have property types modelled at all, and of these 25% take the 705057003 |Presence | value. This largely seems to be a consequence of the pathology synoptic reporting work of recent years.

A better understanding of available property types can only be good for SNOMED CT. As currently worded ‘Issue 2’ does not help this understanding and I am asking for clarification.

Kind regards

Ed

Hi Ed,

Could you post the ECL that you are using to come up with those numbers?

Based on the following ECL, there are only 545 observable entity concepts that contain the property attribute as part of the logical definition in the International daily build browser.

URL: https://dailybuild.ihtsdotools.org/?perspective=full&conceptId1=118598001&edition=MAIN&release=&languages=en
ECL: << 363787002 |Observable entity (observable entity)| : << 370130000 |Property (attribute)| = << 705057003 |Presence (property) (qualifier value)|

I can only validate the numbers you posted in the LOINC Extension
URL: https://browser.loincsnomed.org/?perspective=full&conceptId1=859031010000101&edition=MAIN/LOINC/2026-03-21&release=&languages=en
ECL: Same as above

A bulk of these concept contain either the NHS digital namespace identifier or the LOINC extension namespace identifier.

I just want to be clear about what you mean when you say these exist in the “International Edition”, because that is not what I am seeing.

Thanks

Tested against May 2026 IE data (my earlier analysis was on the April 2026 data)

>> “…Currently only ~2000 (of 11000) IE observable entities have property types modelled at all…”

Total number of IE observables ECL: << 363787002 | Observable entity | => 11040

Number of IE observables with any property type modelled ECL: << 363787002 | Observable entity |: {370130000 | Property | = << 118598001 | Property |} => 1871 concepts (rounded to ‘~2000’)*

>> “…and of these 25% take the 705057003 |Presence | value…”

Number of IE observables with property=presence ECL: << 363787002 | Observable entity |: {370130000 | Property | = << 705057003 | Presence |} => 543 concepts (the same as you get)

543 / ~2000 = 27% (rounded to 25%)

** I actually got this number from testing the April relationships file directly and rounded down from 2122 modelled concepts (because I’d not considered that some of them were evaluation procedures). Taking the more stringent 1871 observables figure the percentage of modelled observables with a ‘presence’ value is even higher - 29%.

Agree, the positioning of ‘presence’ as a property in the SNOMED CT and LOINC meaning is tricky. The defining logical model in SNOMED CT to represent the measured properties has snookered itself when using presence to represent scale types / measurement modalities of the qualitative, semi-quantitative type with applicable degrees of ordinality.

There is a more deeply rooted problem with the model and for me it begins with all attribute relationships being OWL properties. SNOMED CT property then carries its own meaning which appears to me misaligned from VIM metrological definitions - measurement properties (kinds of quantity) vs non measurement properties, but does come from lab medicine (I think!). Anyway, this is the working model in SNOMED CT and so…

I think what the briefing note is referring to within the confines of the current model’s semantics is the lack of connection between the generic level of measurement of a substance / entity, undeath which sits all things qualitative and quantitative. We see this commonly in the microbiology and immunology world where we can’t co-classify those observable entities under a generic measurement of the antibody, organism, organism substance. So it will likely be perceived by some as bending the rules to achieve a desired classification.

Rightly or wrongly, this is the available limited option without a returning to the drawing board and rehashing the model (this would be too disruptive), or having to employ lots of confusing GCI’s on the higher level concepts as Andrew Perry attempted on the UK edition content.

Using the example in the doc:

732171010000106 |Measurement of Aspergillus antibody in serum (observable entity)|

SNOMED CT - Measurement of Aspergillus antibody in serum (observable entity) (sorry won’t let me paste in images)

It’s descendants are all quantitative measurements. The presence concepts will not classify under the generic measurement concept and so they end up separated over in their own hierarchy.

SNOMED CT - Presence of Aspergillus antibody in serum at point in time (observable entity)

Over in the UK we want to say something similar because we are stuck with our old concepts that currently run the test result data like:

999011000000104 | Aspergillus fumigatus 1 antibody level (observable entity) |

These ambiguous ‘level’ concepts currently port the qualitative AND quantitative data from labs to GPs, so we would have needed the more accurate concepts (like those LOINC Ontology ones above) to classify underneath for backwards compatibility, but we plan to potentially use mapping tables instead. This briefing note proposal could mean we revisit using the automated classification.

Thanks Karim for this explanation. Some thoughts:

1. Property types are a precious element of the observables chapter in SNOMED. Indeed they are named in the editorial guide definition of Observables:

“Information about a quality/property to be observed and how it will be observed”

Currently there are approximately the same number of property values as there are approved attributes for the whole of SNOMED CT. Putting these points together (importance and size of challenge) it would seem both desirable and achievable to have a very tight handle on what they are, what they mean, and what happens to them.

2. As such, either before or in time for the introduction of 685451010000100 | Measurement property | to the international edition, it would seem desirable to understand (a) what this new concept ‘means’ and (b) what the other property values ‘mean’.

Point (a) should be simple - defining a single new code. I’m guessing it means ‘those property types which are or can be measured’ - but this then requires further unpacking of ‘can be measured’ so that the other property types, also defined, can be tested against it.

Point (b) is a slightly larger challenge, but I assume has already been partially attempted: Issue 1 presents seven codes which the authors have decided compare favourably, and Issue 2 posits two more - so that’s nine already. And arguably we don’t even need to look at all of the remainder - we can limit ourselves to those property types that are actually in use. Running the following query over the latest LOINC Ontology data here

((<< 363787002 |Observable entity (observable entity)|:{ 370130000|Property|=(((<< 118598001 | Property |))
MINUS
(<< 685451010000100 | Measurement property |))}) .370130000|Property|)

…returns a modest list of only 47 property types used in the LOINC ontology (and the dependent January 2026 IE Release) that are not kinds of 685451010000100 | Measurement property |.

This includes six of the list of seven in Issue 1 (81827009 | Diameter | isn’t used), both the codes in Issue 2, and just 39 more. Tested against my ‘definition guess’ several of this remainder look like they should be members of the 685451010000100 | Measurement property | set (given its goal of providing “…the generic level of measurement of a substance / entity, undeath which sits all things qualitative and quantitative…”) but would be missed if only the changes presented in the briefing note were carried out. I suppose this is covered in ‘Proposed solution 3’ but it seems regrettable not to try and get things more ‘correct’ from the outset.

3. Performing such modest ‘definition’ exercise at this stage would, presumably, improve the performance of 685451010000100 | Measurement property | against its stated goals, and also help explain - clearly - what is meant by ‘presence’ as a property. If a definition comparison reveals it as a true ‘measurement property’ then we need to ask what is being ‘measured’ where it is used in the definitions of recently-added IE concepts such as 1264290008 | Presence of thrombus in renal vein | or 1389350002 | Swede score |?

Kind regards

Ed

Thanks, all, for the feedback. I apologize for the delay in responding due to being on leave.
The concern with “presence” is just as described by Karim in his reply.
Based on the feedback and suggestions received here and by RII, we are reviewing the list of properties used in modeling to look for additional subtypes and developing a text definition for the 685451010000100 |Measurement property (qualifier value)|. Therefore, it is likely a revised BN will be provided (along with a later proposed promotion date). I will provide an update once we are further along in the review.