Modelling of existing content in the Observable Entity hierarchy

I am not aware of any substantial implementations using the SNOMED CT observable content. Pathology has been dominated by LOINC. Other areas of healthcare may have adopted SNOMED CT observables, but we have limited transparency of this and usage. I'd expect whatever decision would be handled as general change management.

As for impacts. The "disruptive approach" of creating new concepts is the safest as implementers and message recipients can easily identify a change has occurred. Though I appreciate a pragmatic approach may be desirable, if taken we would most like generate a list of affected concepts and request all implementations check for the usage of these concepts.

As SNOMED CT is not, yet in wide use in Denmark the Observable entities are not either. However, I do know of a project where our municipalities and regions aim to create a common terminology for general documentation within nursing. Most commonly, they choose a Clinical finding to record what they observe about the patient, but for headings/texts on the user interfaces and for free text fields (when they cannot avoid this) we have encouraged them to use Observables to specifiy the topic that the want to document about. These Observables should preferably have attributes in the Clinical finding hierarchy to specify the actual observations of the patient. As we know they do not always.

This ‘nursing’ set of terminology is not yet implemented as a SNOMED CT refset and I believe any cleanup will be a benefit.

We don't seem to have implementations that are currently using the SNOMED CT Observable Entity hierarchy content. Although not that long ago, our stakeholders have expressed the wish to eventually use this content from SNOMED CT, in the Question-Answer type of format instead of LOINC and SNOMED CT. I think this initiative will provide our future Observable users with a higher quality content.

From the impact perspective, on how to deal with the fix to apply, I like when things are clean and conformant to the guidelines: I would want to see obsolete concepts inactivated and new enhanced, well defined and unambiguous concepts created to replace them. When I asked the question to my stakeholders, they said, please keep the conceptID and refine (behind the scene) the concept, so we are not too impacted by the changes.

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 concepts have been inactivated without associating an 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.

In Canada we won't be really impacted by the fixes (as many other countries), so I think that the countries that have implemented these codes, should express their prefered options and their voice should probably take precedence in how the fix should be applied.

Argentina has recently joined Snomed International and we haven´t used the observable entity hierarchy yet. We are using it for our national nomenclature that will be part of our releases.

About the second item, we consider it would be better to change fully specified names than the inactivation and replacement of concepts.

We do not have frequency data for the usage of these concepts in Norway. It is likely that if they are in use, it is predominantly in the point-in-time meaning.

You propose 3 different solutions to the problem of underspecified concept in the Observable entity hierarchy:

1) Inactivating underspecified concepts and adding specified concepts
2) Changing fully specified name to better reflect likely clinical meaning
3) Applying clinical interpretation when modeling

We advise against changing the fully specified name of concepts that are "underspecified". Even though the predominant usage is probably point-in-time, it would be an error to assume that for every use of these concepts. Applying clinical interpretation when modeling will not solve the usage problem, as far as we can se.

Inactivating concepts seems drastic. SNOMED CT is full of "underspecified" concepts. If the distinction of time aspect (point-in-time, 24 hours etc) is needed, specified concepts could be added as "daughters" of the "underspecified" concepts. However, it is also conceivable that Time aspect is an element that should be solved in the information model, or it could be added to the underspecified concept in a post-coordination procedure.

If specified (pre-coordinated) concepts are added, users could be asked to use these instead of the underspecified ones. Historical data in EHRs, data warehouse or registries would have to be interpreted in context to decide which specified concept it corresponds to.