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 there other tooling requirements that would be impacted? If we keep this matching description, do we want the tooling to automatically assign a language refset, or do we want it to require us to 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. 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 we 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 editorial policy, and for the English edition only.

YGA: from editorial policy perspective, if FSN is not clinically friendly, it should not be entered into a synonym. I agree with the arguments about semantic clearness. The FSN provides that. 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 create a new concept, we create the FSN, tooling automatically creates a preferred term from the FSN, if not clinically friendly, change it.

GRE: Policy started because of request submission some years ago. We can stop it, but some will say we want it, we requested it. It will be nice if you want to discontinue that to provide this kind of notification to the MF. But it was based on a user request. Also I still think it is language specific, let each language decide if need it or not. 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 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 guidelines on how to construct clinically friendly terms. I'm not opposed to doing that, but I think development of 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, 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): our business is clinical interface terminology, but all terms we create we map to SNOMED CT, and we only use the FSN because all the other terms are 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. Others in terms of clinically useful you can use examples from sibling concepts, MCA: or have submitters submit them with the request, which happens now. JCA: yes, but usually not added as the preferred term. MCA: sometimes it is. 

BGO: do we have time to approve the ECE naming patterns? 35:42

JCA: if we can move past this, then yes. So is everyone happy with this direction? (Question about whether an additional description is required.) Yes, a PT is required. The FSN will never be enough. So action item is to go to tooling group to remove the validation error. YGA: turn to a warning, not an error. JCA: there's a warning now, but it creates a validation error. So it should be a real time warning, not sending a validation error through at the time of validation. Change from an error to a warning. Disable the validation rule altogether. You will already have made the decision. 

•  JCA to communicate to tooling decision about matching descriptions.

38:50