|
|
-- pubmed |
|
# Context
|
|
\ No newline at end of file |
|
|
|
|
|
Health professionals are interested in having insights about the drugs they prescribe. An illustration could be to customize the application according to users’ habits while retrieving information either from official guidelines or recognized journal publications as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
That is to say, to be able to link the different medical concepts noted on a particular prescription order to those guidelines. Luckily, the life-sciences part of the [Linked Open Data](https://lod-cloud.net/) LOD is provided with Semantic Knowledge Resources about *symptoms, indications, drugs* ect. A typical use case is to retrieve any information around a prescription order: to validate if the prescribed drugs combination is OK for the patient.
|
|
|
|
|
|
|
|
We will be using a KR representing drugs, [Romedi](https://www.romedi.fr/) an open vocabulary that can understand what is a *BrandedDrug* and its *Active Ingredients* with their corresponding code notation from the ATC.
|
|
|
|
|
|
|
|
The [MeSH](https://www.ncbi.nlm.nih.gov/mesh/) KR is also needed for the final part : querying [PubMed](https://pubmed.ncbi.nlm.nih.gov/) with MeSH terms to retrieve abstracts publications.
|
|
|
|
|
|
|
|
For each of these steps, K-Ware is the way to go. In fact, we need a way to represent and manipulate :
|
|
|
|
- **Literals** : as we have to do some sort of Name entity recognition **NER** between a drug name and an URI from Romedi
|
|
|
|
- **Transverse relation** : as we have to manipulate some *paths* between a **BrandedDrug** to its **Ingredient**
|
|
|
|
- **Mapping relations** : as we have to follow correspondences between an **Ingredient** represented by an ATC code to another coding scheme from MeSH for information retrieval purposes from PubMed
|
|
|
|
|
|
|
|
# Our approach using KWare
|
|
|
|
|
|
|
|
KWare provides atomic representation for these aspects by using the *Type* representation of each *Knowledge Resource* we wish to manipulate conjointly.
|
|
|
|
In KWare terms, what we actually are defining is a **Module**. For this particular usecase, all materials needed are conjointly integrated : many KR (Romedi, MeSH), mappings, indexes (for NER purposes).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On top of this integration by using KWare, we did an application where an health professional can specify its prescription order with an autocompletion. This aspect uses internally the different relationship about *LiteralDefinition* from K-Ware's Type definition, by using them for the creation of a generic index.
|
|
|
|
From a **Romedi BrandedDrug** URI, the mapping mechanism is then employed to link any **Ingredient** to its corresponding **MeSH term**.
|
|
|
|
|
|
|
|
The complexity is per se hided for the end user.
|
|
|
|
|
|
|
|
The terms are then sent to the PubMed querying API, and the corresponding abstracts are shown for the end user.
|
|
|
|
|
|
|
|
Go to [here]() to test it !
|
|
|
|
|
