In a dictionary like CIEL you have 50k concepts and 3-5 times more terms. The concern with the UI for managing terms is that from the current UI it is very hard to keep track of what terms are actually in the system, which terms are unused and there’s no visible connection between terms and mappings from the manage terms page.
@akanter probably has some biases on the matter as he manages the CIEL dictionary. @darius may also have some ideas.
@tmarzeion is a developer, who will put the improvements in place for us.
I would recommend having the team do some interviews with power users of this functions. @ball, @ayeung, and @arbaughj are pretty active on these forums, but I hope you can also find more non-US-based people.
I’m not an authority, but my major initial reaction is that I would prefer for reference terms to be logically grouped underneath the source they belong to. I.e. there’s no “browse all reference terms” but rather you click into SNOMED-CT and then you’re browsing the reference terms in the SNOMED source. And then you have an Add button that lets you add a SNOMED term.
(Conceivably one might want to search across all reference terms.)
PS- My actual use cases have been that after I have analyzed a form (and usually consulted with Andy) I will be creating some concepts (maybe I’m manually replicating a concept from CIEL, maybe I’m creating a new one), and I have a list of reference terms to create, for ICD, SNOMED, CIEL, PIH, etc.
(In practice my use case would be better handled by importing a CSV or JSON, since I’m a dev, which has the side-effect of creating the reference terms when it creates the concept. But we’re talking about the Manage Reference Terms pages.)
hey @raff apologies for it taking almost a week for me to respond to this!
@akanter: Can you please provide me with access to the dropbox folder where the current CIEL exists?
Also - just to sanity check my understanding - can you confirm that the UI for managing reference terms would be used in implementations that wanted to use the CIEL but also needed to to support NDC (National Drug Code). Is this correct:
The FDA would be configured as a concept source
The NDC feed would be uploaded
The interface would be used to manage mappings between the newly introduced NDC codes and preferred concept names in the drug class.
In the scenario of just a basic requirement of being able to map an NDC codes to the preferred concept name for drugs):
@tomgriffin, no worries for the delay. Yes, adding mappings to NDC is a possible scenario. I haven’t planned on adding importing terms in bulk in the first pass.
Another typical use case is when an implementation creates its own source e.g. PIH and comes up with some coding scheme to use terms to reference concepts by the PIH source instead of some other external source like SNOMED.
Technically you are correct, that the source would be FDA-NDC (as there can be more than one code from the FDA) and the NDC codes would be added as reference terms, although related-to does not seem correct. BTW, NDC codes are poor codes to use for drug prescription as they are designed for packaging and dispensing. There will be many, many NDC codes mapped to a single drug concept in the concept table, although fewer would be mapped to drug formulations in the drug table (if and when we allow reference maps to the drug table). BTW, please request the dropbox link via email so that I have that to add you.