Join a community of interest
Standards and specifications to electronically share health information consistently, safely and reliably
Support for digital health implementations
Resources and enablers to accelerate clinical interoperability
What's going on in clinical interoperability and digital health
What this site is about, future plans and how to reach us
Share this page:
Welcome,
Guest
|
|
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! |
The administrator has disabled public write access.
|
|
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 |
The administrator has disabled public write access.
|
|
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! |
The administrator has disabled public write access.
|
|
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 Questions In order to guide the development and enhancement of the Observable Entity hierarchy, we would like to have the following questions answered:
Target date for feedback and comments Please provide your response on this forum before January 25. Thank you! |
The administrator has disabled public write access.
|
Improving the quality of patient care through the effective sharing of clinical information among health care organizations, clinicians and their patients.