Date

25 October 2016

Location

Wellington, New Zealand

Attendees and Observers

See agenda page

FSNs, Preferred Terms, Synonyms and Tooling

JCA: Right now, you enter the FSN, and the tooling creates the matching description. automatically assigns that as the preferred term for English and GB refsets unless there's a known GB spelling in the tool then it creates one for each. are Are there other tooling requirements if that would be impacted? If we keep this matching description? Or , do we want the tooling to automatically assign a language refset, or do we want it to require us to enter a different one if it's pick a more appropriate term for the language refsets if we decide that the matching description is inappropriate for clinical use? They can make the change, but it's a matter if we want it. That would require more work for editors, even when FSN is appropriate as the preferred term you would still have to choose it.

GRE describes how his system works, based on the Workbench translation. JCA: is SCA, you create the FSN and it creates the matching description. I don't think you can go backwards.

JCA: so leave it as it is? Do we require tooling changes so we don't require it if we don't want to?

TMO: how often does this happen where we don't want the FSN to be a preferred term or a synonym? 6:42 PAM: in the ECE work, a lot of those are generating descriptions that are unruly to use and may alienate clinicians.

JCA: the way we currently have it leads to some unwieldy FSNs. Other . We see that a lot in the Kaiser project. But in many cases they're not created. The other burden on the editors is if there is no termwe don't use the default, they have to come up with a clinically acceptable term. 

GRE: from the tooling stand point we should consider an internal editorial policy, and for the English edition only.

YGA: from ed. editorial policy perspective, if FSN is not clinically friendly, it should not be entered into a synonym. i I agree with the arguments about semantic clearness the . The FSN provides that. from From the search perspective, the FSN includes all the key words there. Synonym keep clinically friendly aspect, FSN keep semantic clarity. Redundancy is not necessary. We can give the freedom without the auto-generation. Automation is still necessary. we We create a new concept, we create the FSN, tooling automatically create creates a preferred term from the FSN, if not clinically friendly, change it.

GRE: policy Policy started because of request submission some years ago, we . We can stop it, but some will say we want it, we requested it. it It will be nice if you want to discontinue that to provide this kind of education notification to the MF. It . But it was based on a user request. Also I still think it is language dependentspecific, let each language decide if need it or not. Submissions are usually Also, regarding submissions, they usually have significantly high number of non-compliance and have defects. 

BGO: any thought given to using user friendly names like Kaiser for preferred terms? GRE: there were problems with those. JCA: We talked about it, but the issue is many with many of those terms is that they contain abbreviations and truncations, many are broader than the FSN. All of those are non compliant with editorial policy.

JCA: Back to YGA's suggestion regarding clinical friendly terms when the FSN is not. How do we determine what a clinically friendly term is? need Need guidelines on how to construct clinically friendly terms. I'm not opposed to doing that, but I think development of ed editorial guides on how to create clinically friendly term is as much as a challenge as other things we're discussing. BGO: I agree, our terms are developed in that way, and I can share some of our guidelines so you can see what they look like. JCA: let's talk offline about that.

TMO: if don't create a term that matches the FSN, user the clinician could still search on the FSN. Do we know that they do that? GRE: most of the browsers we looked at searched for FSN too. The word order variance, etc. are supposed to be handled in the lexical tools, not requiring additional synonyms.

JCA: Matter of how find a concept in the first place vs. how is it represented in the system.

IMO rep (Eric): all of our business is clinical interface terminology, but all terms we create we map to SCTSNOMED CT, and we only use the FSN because all the other terms are ambigious or otherwise problematic. ambiguous or non-synonymous. So making preferred term always identical to the FSN has at least the virtue of if 2 terms are identical then that's the best chance that 2 terms are synonymous. To me your proposal sounds like a good idea.

GRE: synonyms are a big problem for English simple many are ambiguous or overlap. 

YGA: if FSN is the best, why need user interface terminology if those are supposed to be used in clinical use?

IMO: we have different clinical terms and map them to the narrowest SNOMED CT term.

GRE: My preference for the core is to have unambiguous FSNs. Anything else is a matter of preference of the language. JCA: I agree, no way we could support all of the world's preferences for synonyms, so they can create their own on top of the core. 

GRE and YGA agree that the user is the one who knows what is the user-friendly term is. It's a matter of the FSN being semantically cleared, and the clinician rarely uses that term. 28:00

GRE: I think we just need to make a decision. A decision is better than no decision. 30:36. as friendly amendment that this is related to the English language and not affect other languages that will have to determine their own policies. YGA: those are extensions, but this policy would affect the core. GRE: original request was because users wanted the option to change the preference rather than having to create a description. Originally changing the preference was easier. 

JCA: so now we're back to where we were when we last discussed this. The current tooling will automatically create a matching description to the FSN without the semantic tag, the editors will make a decision on whether or not the matching description is clinically useful. If it is, it will be maintained in the terminology as the preferred term. Those descriptions that are not will be removed, and we will need to request from tooling that they fix the rules so we don't experience a validation error if matching term is not there. That is what we have decided. Does that sound like a reasonable approach? 34:00

MHA: we do not always know what the most clinically useful term is. How would we find out?

JCA: The co-occurrent and due-to. FSN naming patterns are coming out of the ECE, so we will have a clinically useful naming pattern.