Page tree


Summary

See attached briefing note.


Relevant documents


Actions: 

Date

Requested action

Requester(s)

Response required by:

Comments

11 December 2018Review briefing note and respond
  • Camilla Wiberg Danielsen Please review the briefing note regarding Observables modelling (on this page) and provide a response by   Thank you.
  • Daniel Karlsson - Not applicable.
  • Sheree Hemingway Please review the briefing note regarding Observables modelling (on this page) and provide a response by   Thank you.
  • Elze de Groot Please review the briefing note regarding Observables modelling (on this page) and provide a response by   Thank you.
  • Karina Revirol Please review the briefing note regarding Observables modelling (on this page) and provide a response by   Thank you. 
  • Linda Parisien Please review the briefing note regarding Observables modelling (on this page) and provide a response by   Thank you.
  • Matt Cordell Please review the briefing note regarding Observables modelling (on this page) and provide a response by   Thank you.
  • Olivier Bodenreider Please review the briefing note regarding Observables modelling (on this page) and provide a response by   Thank you.
  • Jostein Ven Please review the briefing note regarding Observables modelling (on this page) and provide a response by   Thank you.
  • Theresa Barry Please review the briefing note regarding Observables modelling (on this page) and provide a response by   Thank you.
Please post your final responses in the Country response table below. Discussion comments can be made as comments.

2018-12-11 - CMAG Meeting

Country response 

CountryDateResponse
Australia

 

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.

Denmark

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.

CanadaModified feedback 31 jan 2019

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.

Netherlands31 jan 2019In the Netherlands the observable entity hierarchy is not widely used. We do use a part in the clincal building models, but also LOINC is used there where relevant. We also did not yet translate the observable entities (only the ones that are used in the clinical building blocks), but we will translate all of them in the next two years (maybe better to wait until this work is done) . As for approach we prefer to change the FSN when the meaning stays the same, because that will not impact our translations (where available). However, when the interpretation could be different, there is a chance the translations differ from theFSNs. Maybe a list of changed FSNs could be made available before the change so we can see the impact on our existing translations. I do encourage the work on this hierarchy, and more clear FSNs will improve our translations (and speed up our translation process)
Argentina31 jan 2019

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.

United Kingdom31 Jan 2019Of the 9836 core concepts in the observable entity hierarchy, we have usage stats covering over 3000 concepts, and in the last year that usage totals over 125 million. We have a further 4,722 UK extension concepts across this hierarchy. We have usage stats for over 4000 of these (a significant amount of which is pathology-related/used in lab messaging), totalling 1.3 billion in the last year. Both options offered at the final bullet point (inactivation with replacement / changing existing FSNs) have the potential to be significantly disruptive for us. The last para in the Briefing Note, before the questions section touches on the modelling of the existing FSN, and this, we feel, warrants further exploration as an option.
Norway13 Mar 2019

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.




Member countries without a CMAG rep


CMAG response

DateCMAG ResponseNext steps










Final outcome: 

Date: 


  • No labels