Request for feedback on the SNOMED CT modelling of existing concepts in the Observable Entity hierarchy

Hi M-A,
Thank you for your comment.

As you mentioned, implementing a terminology that meets implementers needs often means dealing with changes on a regular basis.
This is particularly true when implementations are increasing. Gaps are found, inconsistencies are found and new innovative concepts may bring other perspectives to the content, that was not initially considered, requiring a revision of what is already existing in the terminology.

We are then facing a dilemma when time comes to "cleanup" or enhance the terminology, knowing that the existing content has certainly been implemented. We then want to impact as little as possible the systems and the users.

Just to set some context around your comment, here in Canada (not sure what is the guidance in Belgium), as well as in many other countries, the Observable Entity hierarchy content is probably not as used as other hierarchies. The reason being that often this content is used in the question-answer pattern. The guidance in using this pattern in Canada, is to use LOINC code for the question (or label or title) and SNOMED CT for the answer. Since I did not receive any positive answer to this posting, I'm assuming that most of the CA stakeholders are followiwng this guidance, and therefore the Observables are not used much otherwise.

I welcome the wish to enhance the concept model and revisit the terminology to increase the quality of the concept definition. Although I would like to see the editorial guidelines to be applied (inactivating concepts as ambiguous and creating new less ambiguous concepts), I also think that for those countries that have implemented this content, this might be very disruptive, even if it is spread over many releases...

So what is the balance, between being compliant to the guidelines and supporting implementation in such a way that the systems won't break? I think there will probably a percentage of the content that is really ambiguous and therefore should be effectively retired, because the clinical interpretation will shift when remodeled. In that case, SI should make sure there are associated active concepts to each concepts inactivated. (lately SI has inactivated concept without associating active concept), There will be another percentage of the concept that will require minor change, not impacting the semantic, and for those, I would agree to apply the second option, which is to keep the conceptID to better reflect the likely clinical meaning of the concept.

Anyone from the community, please jump in the conversation, if you have other suggestions or comments!

Hi,

We do not use them yet though we certainly will use some of them related to scales and measures.

Two things are certain in SNOMED CT: you will need to be able to cope with regular and broad scale changes and the FSN is the true signification of the concept. The first is because the terminology evolves and is still vastly imperfect and it will remain a constant simply because it's impossible to make everything perfect at once. Simply no-one has the manpower to do that. The second is a safety rule. The FSN is the meaning of the concept as clear as it was made. Sometimes it is NOT clear. And one should avoid using such concepts. If you did well, you put your own meaning in them and if the definition changes or the FSN changes then the meaning of the concept may and likely will not be the meaning you had put into it. So it must change form ID, so you don't end up mixing potatoes and carrots in your database and kill patients when your decision support will provide you wrong advice because the concept ID is still the same but the meaning has changed.

Yes a major update will inconvenience people a lot. They should plan it in several phases then small branches by small branches, offer additional support on how to manage the change, but not go corrupting the main terminology principle so people will not have to make efforts. If SNOMED starts down this road where will it stop? How many is "inconveniencing many people"? 10 million people in one country how much is that in USA with 350 milion of people and how many in Belgium where 10 million is whole Belgium? 100.000 in 10 countries? One big vendor? One famous research lab? It's just inconceivable they even think of doing this, changing FSNs majorly and not deactivating the concepts. It would mean we just can't trust the terminology ever. We could never trust the meaning of a concept to remain the same in the next version. A clinical security nightmare.

Best regards
M-A

Hi,
This is your last chance to provide feedback on this topic.

Are you using Observable Entity concepts in your SNOMED CT implementation?
If you are, I'd like to know the set of concepts you are using and how impacted you would be if those concepts were inactivated.

Thank you for responding to this message before tomorrow, January 30, end of day!

SNOMED International is reaching out to the member countries to consult with members about the impact of modelling decisions for existing concepts in the Observable Entity hierarchy.

Background
The Observable Entity hierarchy consists of 8936 concepts as of July 2018 of which only 167 (1.9 %) have any defining attributes besides 116680003 | Is a (attribute) | assigned. No attributes were added prior to January 2017, when work on the vital signs sub-hierarchy was implemented . A large number [5954 (67 %)] of concepts have remained unchanged since January 2002.

Issue
Work before 2017 on the Observable Entity hierarchy has been done without using any attributes. Manually maintained layers of primitive intermediate concepts were used as the basis for meaning. During work on the vital signs sub-hierarchy, a semantic gap was found between the fully specified names and any reasonable clinical interpretation and/or use of the concept. For example, many blood pressure observables did not include specification of whether measurements were done point-in-time or aggregated over some period. Likely, a vast majority of concept usage referred to point-in-time measurements. Similar problems are abundant in the whole Observable entity hierarchy.

The issue with underspecified fully specified names can be solved by

inactivating concepts as ambiguous and creating new less ambiguous concepts. However, this will be disruptive to current users of those concepts. For example, in the UK there were about a billion reported uses of blood pressure observables between 2005 and 2016.

either making changes to fully specified names to better reflect the likely clinical meaning of the concept or by applying clinical interpretation of the fully specified name when modelling (without altering the FSN). However, according to the Editorial Guide, major changes to fully specified names should be avoided without creating new concepts . Further, applying more elaborate “clinical interpretation” to fully specified names when modelling can be risky because the interpretation might not be shared by everyone.

Questions
In order to guide the development and enhancement of the Observable Entity hierarchy, we would like to have the following questions answered:

• If you are using or plan to use the Observable Entity concepts, can you provide frequency data related to the use of Observable Entity concepts in your project or organization?
• What is your opinion of balancing the disruptiveness of the inactivation and replacement of potentially large amounts of concepts versus equally large and potentially major changes to fully specified names without creating new concepts?

Target date for feedback and comments
Please provide your response on this forum before January 25.

Thank you!