Have you ever tried to convert a search strategy from PubMed to Ovid or vice versa? It can be a real pain. The field codes in Ovid don’t always nicely match up with the tags in PubMed and it can be difficult to wrap your head around the auto-expode in PubMed vs manual explode in Ovid for indexing terms. Not to mention that there is some functionality that exists in Ovid but not PubMed (such as proximity operators) and in PubMed that doesn’t exist in Ovid (such as the supplementary concepts tag). Yikes!
Why would you want to convert a search strategy between the two, you ask? Don’t they have the same content?
You might want to use features that are available in both databases! Maybe you’re working on a strategy in Ovid MEDLINE, but realise partway through you’d really like to use one of the PubMed subject filters, for example.
Sometimes, you might find a search filter or hedge, but it is written in the syntax of a different interface. Translating a strategy isn’t always easy or intuitive, so automated the process can reduce errors and save time.
Over the past few months, I’ve been working with a colleague to build a tool that automatically converts searches between the two interfaces, and we recently presented our work at the EAHIL/ICML conference in Dublin.
During the conference week, we had dozens of excellent conversations in person and on Twitter, and 138 unique website visitors! Thanks to everyone who provided feedback and suggestions for improvements. We are working hard to incorporate many of them over the coming months.
The tool is freely available at medlinetranspose.github.io. Please feel free to check it out and let us know how it works for you!
In this weeks’ episode of expert searching: hubris edition, I found that I don’t understand PubMed nearly as well as I thought. I’ll confess to primarily being an Ovid user myself. I’ve never found the PubMed interface intuitive. I dislike not seeing my search history on the same page as my results, reading the search history from bottom to top of the page, and not being able to use proximity operators.
But, as an information specialist, one sometimes has to use platforms that one does not like.
In the course of using PubMed last week, I found that my search queries were not being interpreted the way I had intended. My query in Ovid retrieved over 9000 results, but when translated (as accurately as one can translate between the two…), my search retrieved less than half the results!
The solution: When search terms are in quotation marks, PubMed ignores the truncation symbol. My strategy had relied heavily on truncated phrases, all of which were in quotation marks (to avoid PubMed’s automatic term mapping), and all of which were being interpreted as singular rather than plural terms (e.g. “patient outcome*” would search only for “patient outcome” and not “patient outcomes”).
Oh bother! Why can’t databases just read my mind already?!
This bug(?) in PubMed’s system of interpreting logic brings up a few important issues for systematic searching. I spent some time this week figuring out how the system works.
PubMed’s automatic term mapping kicks in when no truncation, quotation marks, or field tags (eg [tiab]) are used (an unqualified search). In the case of an unqualified search, PubMed searches for terms within MeSH, authors, journals, and the phrase index. If none are found, PubMed starts searching for the individual words within a phrase and adding them to your search. To see how PubMed interprets your search query, see the “search details” box in the right-hand sidebar on the search results page. This will show if any automatic term mapping was used, and if so, how.
The main take-away from this experience for me is:
To conduct a replicable and transparent search in PubMed, always in ensure that your search terms and phrases are either: 1) in quotation marks, 2) use truncation, or 3) in the phrase index. Also, never use both quotation marks and truncation at the same time. Otherwise, you run the risk of having your beautifully constructed search destroyed by silly computer logic.
By now, it’s probably no secret that I love crunching bibliometric data. I find that analysing my results — both during search strategy formation and after downloading final results — gives me a broader perspective and see trends that I might otherwise miss.
However, analysing data can sometimes be time consuming and clunky. Data never seems to be in the format that you want it when you need it; the precise tool that you need at that moment hasn’t been invented yet or is otherwise proprietary; the right software for the job requires a programming language you haven’t yet learned, and so forth. Sometimes you want a quick and dirty answer to help develop a strategy and it doesn’t have to be tidy or perfect, but you need it now!
Here’s my quick and dirty trick for analysing your bibliometric [medline] data:
Generate a list of PMIDs from your results (whether your strategy is finalised or not!)
Pop into the data analysis program of your choosing…
The beauty of this trick is that you can copy-paste whatever you are working on at this very moment (provided you’re working with medline data, of course…) and get real-time feedback. No need to mess with clunky software interfaces or retype your strategy.
Generate a list of PMIDs
If you’re using PubMed, this part is easy. Click the “Format: Summary” drop down menu just below the search bar, then select “PMID”. Et voila! The resulting page is a plain text list of PMIDs, taken from the results on the previous page.
Note that the resulting PMID list will show only the citations from the previous page, so you may want to scroll to the bottom of the screen to show the max number of citations per page (200 at the time of this writing).
To extract PMIDs from Ovid:
select all citations (or a range if there’s a lot!)
select “excel” under the drop-down menu “Export To:”
select “custom fields”
under “select fields” (beside the “custom fields” radio button), unselect everything except “unique identifier” (this is the field that contains the PMID in Ovid)
Then select “export citations”
An excel file should download with a column of PMIDs, which can then be copied/pasted.
(Thanks to Michelle Fiander for the excel tip!)
Analyse your data
Once you have your list of PMIDs, you can pop them into a variety of different tools to crunch the data in different ways. For example, try pasting your list into:
PubReminer – for a word count analysis of authors, journals, MeSH, title/abstract words…
And more! Someday I intend to write up a full list of medline data analysis tools freely available online, but that day is not today…
Why would a person bother to do this?
Building a search strategy is an iterative process and it requires using a lot of different tools. For example, you can use your own common sense and intuition, but other tried-and-true strategies include: backwards/forwards citation chaining, talking to experts in the field, or looking at highly cited papers/journals in the field.
Using quick data analysis strategies throughout the process of building a search strategy will help ensure that important concepts aren’t missed. They provide a more objective picture of what’s happening, what’s missing, and how you can better refine your strategy.
That’s it for this week!
PS This is my first proper blog and I must say… keeping a blog up to date is not as easy as I thought. Please do let me know if you find this content useful and I will try my utmost to keep ’em coming! You can use the site contact form or find me on twitter at @v_woolf.
However, a few days ago I was struck with an awkward problem. I needed to find the total number of citations in Ovid Medline. Why? I had conducted a straightforward scoping search for a researcher and created a basic frequency analysis of the number of citations retrieved in the search per year to show the publishing trends in the topic over time.
The researcher asked me to normalise the data…. say what?? Do I look like a statistician?
I knew I couldn’t use the numbers from PubMed, because the two have slight differences in content. And I couldn’t translate my strategy into PubMed because it relied heavily on the adjacent operator (which is absent in PubMed).
After some frantic searching, I found out that this was not such a difficult task: all I needed to do was take the number of citations retrieved from the search in a given year, and divide this by the number of total citations published in the database that year. This would even out any potential errors in the chart from anomalies in the database as a whole.
The problem: I could not find an equivalent operation in Ovid Medline to PubMed’s all[sb] command. After combing through Ovid’s documentation, I finally broke down and tweeted them… and received a response within a few hours.
@WKHealthOvid is there a way to retrieve total citations in ovid medline, similar to all[sb] in pubmed? thank you! 🙂
I know everyone’s been waiting with bated breath to find the answer: it’s docz.dz.
What does the .dz field code stand for? No idea. But anyway, it seems to get the trick done, and now I have my nicely normalised graph. In the second image, below, you can see that the downtick in citations for the year 2016 has vanished, because the number of citations retrieved from the search is proportionate to the total citations published this year.
Happy story! The end.
PS Cheers to Ovid’s social media team! They are totally on the ball.