As part of BAH-310, we are trying to implement search by concept reference term code.Until now we were not showing the code the auto complete drop down @angshuonline @darius @mksd Please suggest UI for the auto complete. Currently the one in OpenMRS looks like this:
(i.e.)code concept full name (if searched by code or full name)
OR
code synonym a.k.a full name (if it matches synonym)
Should we do the same thing in Bahmni too?
This is a pretty nice search, but it would have to be a preference which concept_reference code would be shown. I actually don’t like seeing the code first, but that might be a public health preference. When I see a lot of results, I like to see the concept_name first followed by the reference code. When searching by code, it would have to search all mapped concept_reference codes, so that you can search by ICD-10-WHO or SNOMED or LOINC, etc.
I agree with Andy on putting the names before the codes if that is permissible.
Also, if possible I would prefer to have leading matches (i.e. those names that actually begin with “col” in the first word) listed before the matches where “col” appears later in the matched text. I would expect that the user has a term in mind that begins with “col”, and can be confused if that intended match comes far down in the list, below a lot of words where “col” is in a later word.
Can we make the changes in OpenMRS (and, thereby Bahmni) rather than having different behavior?
I’m not sure “a.k.a.” translates into all languages. Historically, we used an arrow (assuming search matches synonym):
Synonym ⇒ Full Name (code)
I agree with Burke. I am not sure of a.k.a. Also in Bahmni, in some places (For autocomplete), we already follow the depiction Burke suggested. I also think the code should just appear within braces, if at all.
I’d support changing the “a.k.a” to a =>
Also, I believe we (PIH) were the original use case for the diagnosis widget, but I don’t remember if there was a specific request to have the code first or if it was just a arbitrary decision made at some point… @ddesimone @ball @darius do any of you happen to remember? I wouldn’t be opposed to switching it around so it appears in braces at the end.
Also, for what it’s worth, I believe that a global property determines what source code to display (ie ICD-10-WHO or SNOMED, etc) but certainly could see more advanced configuration. I forget off the top of my head if the search only searches the source set in the global property, but I suspect that is the case.
Finally, per @burke point, I don’t know if there is some way that Bahmni could leverage this widget directly (and we could modify/expand it’s behavior if necessary) rather than creating a whole new widget for Bahmni.
Take care, Mark
Agree with the others about the positive changes (aka to =>; name before the code). I don’t recall having a discussion about it when we were working on it. @darius made it work quickly and seamlessly. It’s held up pretty well but the new suggestions just make it better.
e
+1 to these suggestions. The current behavior (code first and a.k.a.) are decisions I made arbitrarily in the early days of Mirebalais.
About sorting the results, I believe I wrote some hacky code that sorts in java after the DB query based on putting exact matches first and preferring matches on preferred names over synonyms. Ideally we would replace this with more intelligent sorting done natively in Lucene, but that may be out of scope for the current ticket.
There is a piece of code in EMR API that raises question, here:
public List<ConceptSource> getConceptSourcesForDiagnosisSearch() {
ConceptSource icd10 = conceptService.getConceptSourceByName("ICD-10-WHO");
if (icd10 != null) {
return Arrays.asList(icd10);
} else {
return null;
}
}
Q. Why should we assume a general scenario where multiple concept sources might be returned? Is there really valid use cases for this? Is this for an hypothetical scenario where ICD-10 isn’t actually used and diagnoses are coded across multiple other sources?
There will be most definitely situations were there are more than one mapped reference code. Not only do most diagnoses have maps to both SNOMED and ICD-10, but there are different maps to each depending on whether the map is a primary or secondary code mapping. For specific sources, there should not be two SAME-AS maps to the same reference code source. However, there can and will be multiple non-SAME-AS maps.
In my experience, while a concept must support multiple codes, the workflow followed a doctor or data clerk who is recording the patient’s diagnoses would only use a single coding system (often ICD10, occasionally some country-specific coding system), but they would never be typing SNOMED codes.
So I’m not sure we need to support more than one concept source here. (But I probably wouldn’t remove that feature…)
As Andy mentions the current code has a defect where it ignores map type. I think we should be searching only for concepts whose map type is SAME-AS or NARROWER-THAN the code. (@akanter can you confirm that’s a good enough approach? I hope we don’t need to do anything much more complicated.)