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

Naming

BGO: for x-co-occurrent with Y we were proposing X and Y as the preferred term. For co-occurrent and due-to pattern we were proposing X with Y. Due to, following, and caused by are self-explanatory.

JCA: so there's 5 naming patterns:

1. simple occurrence, where you have 2 things that are temporally occurring. That would be simply Disorder X AND disorder Y
2. X DUE TO Y
3. X after Y, which would be X FOLLOWING Y as the preferred term
4. X co-occurrent and due to, which would be X WITH Y as the preferred term
5. X CAUSED BY Y, which is the material side of the due to

40:15

Observer: I don't think X with Y is synonymous in anyone's thinking with co-occurrent and due to. If a clinician says I have hypertension with renal failure, the renal failure might be due to something other than the hypertension. 

BGO: if creating a pre-coordinated concept with both of those then the assumption is that there is a cause relationship otherwise you would document them separately.

Observer: I could probably think of some circumstances when you wouldn't do that. I would think you would want a solution that is unmisinterpretable. 

GRE: even if a preferred term has to be user friendly and reference the same concept as the FSN. If not, they are not synonyms. I agree that WITH in this interpretation is a little ambiguous. With regards to co-occurrent and due to i think there are some problems. But if there is an established policy then I will not bring it back to the table and open up that discussion again. But if you attach synonyms sometimes you will attach more confusion. That's why in Spanish we have to translate literally what they meant, to allow users to create the other concepts. 

PAM: is that true even in the context of having AND, meaning two things that are together and not related. Makes the assumption that everyone understands that rule.

GRE: we make distinctions that are not necessarily done in clinical use. Associated with is potentially a semantic property we didn't have. The others are directional. 

JCA: in terms of naming the approach 4 out of the 5 are straight forward because directional and easy to understand. But WITH means many many things in the terminology right now, attempt here is to make it mean one thing in the terminology, and I would hope the people using WITH as a term would return to the FSN to understand the full meaning before using it. But lots of times people use terms that they don't understand. We don't have any control over that. I think our responsibility is to be as clear as possibly can about meaning and context, if limit WITH to one thing then we've achieved the clarity in the terminology, though maybe not in clinical use. The meaning of WITH would have to go into the editorial guidelines.

PAM: if looked at all of the other instances in which WITH is currently being used outside this context, would you remove those descriptions? JCA: We wouldn't if in fact current term is co-occurrent and due to, but if wasn't, then it would be targeted for removal.  PAM: I've got no idea of the numbers. JCA: by product of using WITH in a singular way would affect lot of terms already using WITH.

YGA: we need to tidy up the existing content already because there is ambiguity. Then it would be much clearer.

BGO: that would be a major project, about 15-20 terms used to describe these conjunctive disorders. 

BGO: so do I have approval so I can go and put that into the editorial guidelines?

JCA: Yes. 

The AG approved BGO's proposal on the 5 naming patterns: AND, DUE TO, FOLLOWING, WITH and CAUSED BY.

49:39

Organizational groupers

JCA: from Editorial Panel, guidance on creation of a policy on fully defined grouper concepts that are not clinically useful but are primarily used for navigation of the hierarchy. Lots of these top-level groupers, like procedure by site, infectious disease by organism, infectious disease by site. All are groupers and are fully defined, but they don't provide any clinical usefulness in many cases. So question is whether there's value in maintaining them; we've had requests to create new groupers because people want help in finding something within the terminology.

BGO: isnt there a requirement in harmonization with ICD11 to have top-level groupers? JCA: not that I'm aware of. BGO: I thought Jim Campbell said they would. MHA: was that when we were going to create a common ontology, which is no longer the case.

GRE: I was part of ICD11 group and idea was to have that. Would require significant collaboration but not sure that has happened. But many many concepts that were moved to navigational concepts some time ago, many are fully definable groupers, and those are a problem because they are active concpet hanging off of navigational concepts. They have no semantics. I am in favor of approving this policy, I think we should revise the navigational concepts to see if some already there that could be fully definable to avoid duplication. Eventually after fully definable groupers, whether navigational concepts should be there could be examined. And a friendly amendment: those groupers should have no stated subtext.

JCA: that's a good general policy.

GRE: Then we start enforcing the policy of fully definable and defined groupers that should not have subtypes, and then we start cleaning them up. 56:00 So idea will be not only to accept fully definable groupers, but also to create a policy that fully definable groupers should not have a subtype, and if they have, then remodel them. 

Observer: there's a mix of things in there, so identifying them will be tricky.

GRE: Reason I think this should be supported is that extensions are getting groupers that are not clinically useful. It complicates things and creates duplication in extensions, so I think this will be a good policy and not collide with anything else. 

JCA: So to sum up, your proposal, Guillermo, is from a navigational standpoint these provide value, if they are added to the terminology, they should only be added if they can be fully defined. Any of these should never have stated subtypes, and essentially the classifier will be used to put them where they may once these are done, and they do have some practical usage. If it provides a simplified way for people to create subsets that are useful in a particular implementation, then all the heavy lifting is done by the classifier and there's not much of a maintenance issue. 59:36

BGO: asks for clarity on groupers that are disease X associated with another disease. It's the only concepts that I can think of that that are modeled using associated with that need to be modeled that way because they subsume more specific subtypes of associated with, so are we going to keep those?

JCA: with any policy there are exceptions, so when we have things like that are not quite clear like that from a classification standpoint, whether or not those are fully defined at this point, they're using associated with, so we're not differentiating between the causality and the temporal aspect of it, it's an association, that would almost require that we have subtypes, like disorder temporally associated with a disease and a disorder causally associated with a disease as groupers. Without additional clarity, the question is how useful is something at that high level?

BGO: personally I think they're not clinically useful. 1:01:08

JCA: Many of these are not useful, clinically, but they may be navigationally useful.

BGO: Navigationally people would be querying with associated with, and you want to get people away from doing that.  

GRE: clinically useful here seems to be restricted to what the clinician will use for capturing, but sometimes clinical use can mean a secondary use, such as analyze or report. That's why the users are adding those. 

JCA: Looking at it from the perspective of maintaining useful subsets of SNOMED, if one defines an intentional refset based on these groupers, then the updating of the value set that is derived from that intentional refset, it's automatically handled in every release rather than needing a manual inspection and recreation of a reference set where the groupers don't exist. And I think there is some value in that. Easier for users to subset SNOMED.

MHA: asks GRE to repeat a point.

GRE: (off mic) Some groupers were not defined or clinically useful, but users continued creating them.

MHA: so is the proposal to move groupers under navigational concepts?

GRE: (off mic) 

JCA: gave example of "abnormal," pointing out that what's abnormal in your facility may not be considered abnormal in another facility. ...many of these can be fully defined. But if we do it, they will infer things that are not necessarily true, and I think that was the primary reason they were retired in the first place. (dead mic).

JCA: do people feel comfortable with GRE's proposal that these groupers should not be disallowed so long as they fulfill the minimum requirements of being definable, have no stated subtypes, and where there are problems they be remodeled.

JCA: happy with that. 

The AG agreed that groupers should be allowed so long as they fulfill the minimum requirements of being definable, have no stated subtypes, and where there are problems they be remodeled.

Next: use case to get ideas on how can provide ed guidance on app use of SNOMED given variable degree of granularity out there especially with structured work like CIMI and FHIR. How do you achieve semantic interoperability given the different levels of granularity? 1:11:33 in terms of editorial guidance, this may be out of scope for this group. 

Break