Changes to 706437002 |Container (physical object)| and the physical object MRCM

Briefing Notes
,
1

Briefing Note Purpose

A request to expand the MRCM for the physical object hierarchy. Goals:

  1. Enable precoordination and postcoordination of prefabricated specimen containers (e.g.
    which contain coating, separator and additives that have been applied by the manufacturer)
  2. Enable precoordination and postcoordination of specimens linked to a particular container
    and/or containing additives.
  3. Reorganise the existing content that pertains to container types, removing duplicate
    concepts and improving definitions of the remaining concepts. This includes the substance hierarchy with respect to coating and additive substances.
Date created 26 xxx 2025
Action Feeedback requested
Status For comment
Disposition Open
Feedback by March 15, 2026

20260131 Revised briefing note - Changes to MRCM for container type modelling.pdf (976.0 KB)

Updated briefing note: Changes to 706437002 |Container (physical object)| and the physical object MRCM
2

A few immediate thoughts:

1. SI’s general design philosophy for device modelling is unclear.

As the briefing note indicates, a number of device-relevant attributes have already been introduced. These ‘grammatically’ apply to the entire << 260787004 |Physical object| domain but (quite reasonably) are only ‘sensibly’ relevant to a smaller number of device types.

This ‘container’ exercise takes a different approach, introducing new attributes, specifying that they apply to a much narrower domain (plus reorganising the content to conform).

Both approaches (define globally and only use where appropriate (probably by template-level constraints) vs. define locally) are valid, but - at this very early stage in SCT device modelling - there is an opportunity to adopt a single approach and use it consistently. The new proposed attributes (‘has additive’, ‘has separator’ and ‘intended content’) are unlikely only to be applicable to ‘specimen container’ type devices, so will need to be restated (possibly with definition, cardinality and range modifications) as and when they are applied to other device types. By contrast, if they were also specified at the level of ‘physical object’ they could be declared mandatory or profiled out/ignored (using e.g. template specifications) as needed (which is broadly what happens in other parts of the terminology).

If, on the other hand, SI wishes - in the long term - to specify multiple device type domains (of which I imagine there will be many), then there is an opportunity to rework the published attributes now so that we can understand what general design philosophy is planned. We then might reasonably expect (the many) device model specifications to be simultaneously ‘grammatical’ and ‘sensible’ (with considerably less need for template profiling for each device type).

2. The briefing note title refers to ‘changes…to the physical object MRCM…’.

a. sorry to be pedantic, but whilst it is not wrong to say that the MRCM will change, the proposal is a conceptual one - it is the ‘SNOMED CT physical object concept model’ to which the proposed changes would apply. The MRCM is simply a machine readable rendering of certain elements of the ‘concept model’.

b. The ‘Has additive’ attribute proposal names two domains (‘Container’ and ‘Specimen’). As such the briefing note is also a proposal to ‘change the SNOMED CT specimen concept model’ and should be presented as such. It is likely, for example, that the current usage definition for ‘specimen substance’ (“…the type of substance, pharmaceutical/biologic product, or physical object of which a specimen is comprised…”) will need to change in order to exclude ‘specimen additives’ which would be handled by an alternative means).

3. Links

The briefing note contains a number of links beginning “https://nl-authoring.ihtsdotools.org/…”. I am unable to reach the pages they specify. If the content is valuable for reviewing the proposal please could it be made available?

Thanks Ed

1 Like
3

@jcase Is it possible to provide Ed and authors with viewing rights to the project EXAUTHTEST?

4

@fhielkema

I am afraid we are having difficulties in granting access to the TS browser. What I can recommend is the creation of a set of modeled example images that cover the different approaches to modeling the content and make those available for general consumption.

5

@echeetham Yongsheng and Kai very kindly solved the access problem for us:

With Kai’s help, it is uploaded to the subontology browser, which external users can access. You can view the subontology here:

https://subontologies.snomed.tools/?

The following is the link to 706049005 |Blood tube (physical object)| in this subontology

https://subontologies.snomed.tools/?perspective=full&conceptId1=706049005&edition=MAIN/SNOMEDCT-BLOOD&release=&languages=en

6

Hi Feikje

I really appreciate your efforts in making the test browser available. As a general observation I think this is an excellent way of socialising design ideas (in particular with external/user audiences) and it would be helpful if SI could figure out a reliable and reproducible workflow to (a) give easy access to authors/editors that allows them to produce this sort of test data and (b) make the results available as a routine part of all model-type briefing note proposals.

Some more thoughts:

a. whilst the work is presented as a ‘proof-of-concept’ it’s not clear to me what ‘concept is being proved’ or what we should conclude the outcome is (is it, in any sense, a ‘success’?). We know by now what will happen when content is defined in this way, so the modest reorganisation and classification beneath 706049005 |Blood tube (physical object)| is unsurprising and largely unremarkable. Modelling doesn’t appear to have detected any duplication/redundancy, and the proposed concept definitions are (a) incomplete and (b) still seem reliant on a number of quite detailed proximal primitives (a design paradigm which is discouraged elsewhere in SNOMED CT).

b. The list in Appendix A (‘the requirement’) has not been included in the modelling so it is unclear how comprehensive the proposal is in dealing with the differentia these containers require. The ‘Container for… (IGRA) for tuberculosis TB1’ pattern seems to stretch beyond any achievable modelling, and I also note use of ‘without’ in some of the terms (e.g. ‘Urine container without additive’). How would these be addressed? Building on the second (‘without’) point I do wonder whether ‘containers with additives’ strays into the territory of combination drugs (stents and cannulae with additives certainly should) and therefore whether there are use cases that need to distinguish formally between ‘a tube that contains sodium fluoride’ and ‘a tube that contains ONLY sodium fluoride’? The briefing note touches (for other purposes) on ‘active ingredient count’ used in drugs and I wonder if there are device use cases that may need to a similar approach (which may include count=0 for the ‘container without additive’ cases). Clearly beyond your use case, but have you considered devices such as ingestible sampling capsules which are ‘containers’ to which the patient is directly exposed?

c. Returning to my earlier point of keeping track of what is happening across devices as a whole: Currently there are four ways of associating a device with a substance:

  • Has compositional material
  • Has coating material
  • Has filling
  • Has active ingredient (from the drug/device cross-over)

This proposal adds two more:

  • Has additive
  • Has separator

Given that only 10% of devices are role modelled at all, and only about 2% are sufficiently defined in the latest international data, do we have any sense whether we’ve hit the device=substance attribute ceiling, or may it continue to grow as additional device subdomains are investigated? I appreciate the various distinctions that are being invoked to justify each attribute, but at some level of abstraction there may be scope for refactoring/simplification. Establishing what an entire device is ‘made of, coated with, contains or releases’ (‘the sum of all substances’) may become unhelpfully complex. Furthermore, the text definitions for ‘has separator’, ‘has additive’ and ‘intended content’ all specifically refer to specimens, which would appear to limit their scope considerably. Surely there are other ‘devices’ to which these attributes may be applicable?

d. Building on the refactoring/simplification point, I worry that the ‘post-coordination’ use case (given primacy in the briefing note) is a high risk strategy at this point. Safe machine-interpretation of post-coordination is highly reliant on a stable definitional model. SNOMED CT offers not systematic mechanism for analysis and classification over changing models, so the question has to be asked - how stable is the ‘device model’? A few years ago a model based on ‘Has device characteristic’ and ‘Has surface characteristic’ was published and subsequently withdrawn. Device modelling is highly reliant on detailed proximal primitives which is also likely change over time. The proliferation of device-substance attributes may well change as more device sub-domains are investigated. Some of these changes could be handled (for purposes of safe analysis) with basic concept-level history mechanisms, but for others this will not be possible and will lead to flawed classification and analysis.

The proposed ‘container’ model is almost certainly not perfect, however I am not arguing that it wouldn’t be useful as a tactical ‘holding position’ to help organise content to meet the needs of the X-eHeath work. However I predict it will change (disruptively) as more device sub-domains are investigated and integrated. I would therefore urge you to pursue a precoordinated-only approach in the short-medium term. This may require a more exhaustive initial requirements-gathering and a larger set of container type codes, but it will insulate the content identified from the risks of a changing model.

There are other points (like a topological explanation of why 706049005 |Blood tube (physical object)| is not a kind of 83059008 |Tube, device (physical object)|) but I will stop for now.

Thanks again.

Ed

7

Hi @echeetham , Thank you for these considerations! You make a number of interesting points. Will you be at the Business Meeting in Vienna and if so, could we have a chat prior to the EAG meeting, to discuss whether there are any changes we should make to the proposed MRCM changes? In particular:

  • The scope of the changes: should they apply to all objects, only containers, or only specimen containers?
  • Should we equate blood tube with a specimen container meant for blood, and thus move it out from under tube (object)?

I’ve had a look in the subontology browser, which I should have done before. It appears to be missing the concepts I added; it only contains the changes I made to international concepts. That is a pity because those new concepts show the benefits most clearly. E.g. 1384176008 |Blood tube with clot activator (physical object)|, which is sufficiently defined. It has 0 stated children but 14 inferred descendents – there lies the real added value. Without the proposed MRCM changes, that concept would be yet another proximal primitive parent.

We have a trade-off between adding as few attributes as possible, in order to avoid complicating the model unnecessarily; and in keeping the number of proximal primitive parents as low as possible. The EAG members have helped me keep the number of attributes down - which means we indeed retain more proximal primitives than I would like. This is most visible in the existing core concepts. Those distinguish between evacuated and non-evacuated blood tubes, which is not done by any of the concepts Xt-eHealth wishes to add.

I have not considered medication or any containers other than specimen containers. We want to avoid an active ingredient count because that would preclude the use of postcoordination to specify more additives. I admit that I am somewhat sceptical of the ‘without additive’ concepts myself, but we can defer deciding whether to add these: they would be primitive in any case and as such do not affect the concept model changes.

Has separator must be a separate attribute because its range is not limited to substance: it includes physical barriers as well. I suppose we could choose to simplify the model instead, by replacing the attributes has filling & has active ingredient with a new attribute has ingredient – which could serve for additives as well. However, that would create a large disruption for the drug hierarchy, which I prefer to avoid. And there is precedent for multiple attributes between hierarchies: there are, for instance, no less than 5 attributes for associating a procedure with an object.

Which brings me to your final point. I agree that postcoordinated content must be treated with caution. Not just against instability in the MRCM: ‘ordinary’ remodelling done by the QI project to improve content quality can have an impact just as large on postcoordinated strings that are not maintained. But people do split concepts into multiple pieces of information, using data models - and whether the SNOMED MRCM has an attribute for it or no is generally not a consideration in that decision. Many labs will want to record some additives separately, esp. if they were added at the time of the specimen instead of time of container manufacturing. They won’t choose to use precoordination merely because the MRCM doesn’t support the postcoordinated version. With the proposed change, we hope to solve a boundary problem that already exists.

8

Thanks Feikje

I am afraid I am unable to attend the Vienna meetings so it it unlikely we will be able to have any discussion prior to the EAG session. I am also unable to attend the EAG session having already committed to dial into the Mental Health CRG which is also on Monday afternoon.

The question I ask myself is whether I could explain (and defend) - to a third party - the content and changes we see happening in SNOMED CT. At the moment - for devices - I don’t think I can. This proposal is largely valid from a tactical POV but - as I hope I have explained above - is incompletely reconciled with any ‘bigger picture’ of what has already happened or what will happen in the future (I suspect because that ‘bigger picture’ simply does not exist). This is why I don’t have a problem with the container proposal being used to meet immediate requirements but have no confidence that it will survive deeper consideration (hence my caveats about the risky business of ‘post-coordination’ - I know that coherent clinical ideas are frequently split across data model elements, but dispersed models generally don’t market themselves as being able to support future equivalence detection and subsumption the way SNOMED CT does).

As a relatively immature chapter (from a modelling perspective) - there is an opportunity to establish broad principles to the way physical objects/devices will be approached. Building a DL-based clinical device ontology is a huge task and needs to be done in a thoughtful and coordinated manner. The points I raised back in early February speak to this but it is unclear whether SI agree or not.

At the moment modelling in this chapter is already, at best, idiosyncratic, both in terms of its execution (is a 118309001 | Titanium sapphire laser device | really ‘composed of titanium’ in any meaningful way?) and its design (e.g. the piecemeal proliferation of device=substance attributes - the comparison with procedure device attributes is valid in terms of numbers but at least they have been organised into a role hierarchy to simplify analysis). So could I explain what SI are trying to do - no.

It is unfortunate that the demonstration data did not include all your work - this would have been helpful to see.

Finally, on the topic of ‘tube’ and ‘blood tube’ - I only mentioned this in passing as a nod to the typically problematic (? English) language in some of the ‘primitives’ involved (the appendix A list at least includes ‘bottle’, ‘container’, ‘tube’, ‘syringe’ - all playing a ‘container’ role plus the outlier ‘swab’). SNOMED CT’s 83059008 | Tube | mostly subsumes ‘open-ended’ cylinders (such as endotracheal tubes) and does not currently subsume 706049005 | Blood tube | (which it is probably correct), but I note that:

<< 706046003 | Specimen receptacle | AND << 83059008 | Tube |

…does currently return a few ‘tube’-shaped ‘containers’ (which it probably shouldn’t). This is the sort of careful and wider consideration I would expect SI to be undertaking in its device modelling but I have no sense of whether this is happening or whether it is even planned.

Kind regards and have a good meeting

Ed