In some upcoming posts I will address various problems related to the changing interfaces of bibliographic databases.
We, librarians and end users, are overwhelmed by a flood of so-called upgrades, which often fail to bring the improvements that were promised….. or which go hand-in-hand with temporary glitches.
Christina of Christina’s Lis Rant even made rundown of the new interfaces of last summer. Although she didn’t include OVID MEDLINE/EMBASE, the Cochrane Library and Reference manager in her list, the total number of changed interfaces reached 22 !
As a matter of fact, the Cochrane Library was suffering some outages yesterday, to repair some bugs. So I will postpone my coverage of the Cochrane bugs a little.
And OVID send out a notice last week: “This week Ovid will be deploying a software release of the OvidSPplatform that will add new functionality and address improvements to some existing functionality.”
In this post I will confine myself to the PubMed Clinical Queries. According to Christina PubMed changes “were a bit ago”, but PubMed continuously tweaks its interface, often without paying much attention to its effects.
Back in July, I already covered that the redesign of the PubMed Clinical Queries was no improvement for people who wanted to do more than a quick and dirty search.
It was no longer possible to enter a set number in the Clinical Queries search bar. Thus it wasn’t possible to set up a search in PubMed first and to then enter the final set number in the Clinical Queries. This bug was repaired promptly.
From then on, the set number could be entered again in the clinical queries.
However, one bug was replaced by another: next, search numbers were disappearing from the search history.
I will use the example I used before: I want to know if spironolactone reduces hirsutism in women with PCOS, and if it works better than cyproterone acetate.
Since little is published about this topic, I only search for hirsutism and spironolactone. These terms map correctly with MeSH terms. In the MeSH database I also see (under “see also”) that spironolactone belongs to the aldosterone antagonists, so I broaden spironolactone (#2) with “Aldosterone antagonists”[pharmacological Action] using “OR” (set #7). My last set (#8) consists of #1 (hirsutism) AND #7 (#2 OR #6)
Next I go to the Clinical Queries in the Advanced Search and enter #8. (now possible again).
I change the Therapy Filter from “broad” to “narrow”, because the broad filter gives too much noise.
In the clinical queries you see only the first five results.
Apparently even the clinical queries are now designed to just take a quick look at the most recent results, but of course, that is NOT what we are trying to achieve when we search for (the best) evidence.
To see all results for the narrow therapy filter I have to go back to the Clinical Queries again and click on see all (27) 
A bit of a long way about. But it gets longer…
The 27 hits, that result from combining the Narrow therapy filter with my search #8 appears. This is set #9.
Note it is a lower number than set #11 (search + systematic review filter).
Meanwhile set #9 has disappeared from my history.
This is a nuisance if I want to use this set further or if I want to give an overview of my search, i.e. for a presentation.
There are several tricks by which this flaw can be overcome. But they are all cumbersome.
1. Just add set number (#11 in this case, which is the last search (#8) + 3 more) to the search history (you have to remember the search set number though).
This is the set number remembered by the system. As you see in the history, you “miss” certain sets. #3 to #5 are for instance are searches you performed in the MeSH-database, which show up in the History of the MeSH database, but not in PubMed’s history.
The Clinical query set number is still there, but it doesn’t show either. Apparently the 3 clinical query-subsets yield a separate set number, whether the search is truly performed or not. In this case #11 for (#8) AND systematic[sb], #9 for (#8) AND (Therapy/Narrow[filter]). And #10 for (#8) AND the medical genetics filter.
In this way you have all results in your history. It isn’t immediately clear, however, what these sets represent.
2. Use the commands rather than going to the clinical queries.
Thus type in the search bar: #8 AND systematic[sb]
And then: #8 AND (Therapy/Narrow[filter])
It is easiest to keep all filters in Word/Notepad and copy/paste each time you need the filter
3. Add clinical queries as filters to your personal NCBI account so that the filters show up each time you do a search in PubMed. This post describes how to do it.
Anyway these remain just tricks to try to make something right that is wrong.
Furthermore it makes it more difficult to explain the usefulness of the clinical queries to doctors and medical students. Explaining option 3 takes too long in a short course, option 1 seems illogical and 2 is hard to remember.
Thus we want to keep the set numbers in the history, at least.
A while ago Dieuwke Brand notified the NLM of this problem.
Only recently she received an answer saying that:
“we are aware of the continuing problem. The problem remains on our programmers’ list of items to investigate. Unfortunately, because this problem appears to be limited to very few users, it has been listed as a low priority.
Only after a second Dutch medical librarian confirmed the problem to the NLM, saying it not only affects one or two librarians, but all the students we teach (~1000-2000 students/university/yearly), they realized that it was a more widespread problem than Dieuwke Brand’s personal problem. Now the problem has a higher priority.
Where is the time that a problem was taken for what it was? As another librarian sighed: Apparently something is only a problem if many people complain about it.
Now I know this (I regarded Dieuwke as a delegate of all Dutch Clinical Librarians), I realize that I have to “complain” myself, each time I and/or my colleagues encounter a problem.