The Beers Criteria, widely used by healthcare professionals, list so-called Potentially Inappropriate Medications (PIMs) which older adults in certain circumstances should avoid. Manually identifying medications that belong to the Beers Criteria can be time-consuming and error-prone, as the criteria are complex and subject to frequent updates. Moreover, it is not available in a (formal) representation that health systems can interpret and reason with automatically. This paper proposes an ontology as a formal representation of the Beers Criteria, and describes the elements and the taxonomy underlying the ontology. We include inference rules to enable automated detection and categorisation of drugs classified as PIMs. By automatically detecting drugs that belong to the Beers Criteria, the ontology, once linked with decision support systems, can be used to support healthcare providers in ensuring that older adults receive safe and efective medical care. Ontology, Inference rules, Potentially Inappropriate Medications, Clinical decision support system.
Medication mistakes are a primary cause of avoidable patient harm [
Over time, it is common for people to develop one or more chronic conditions, aka
multimorbidity, and their management generally requires them to take several medications. For
older patients, it becomes particularly important to identify the diferent types of drugs that
constitute so-called Potentially Inappropriate Medications (PIMs). PIMs occur due to variations
in the absorption, distribution, metabolism, excretion and physiological efects of the drug [
Monteiro et al.[
The main focus of our paper concerns the knowledge representation and reasoning of
PIMrelated constraints by means of an ontology. The Beers Criteria, which lists PIMs, can be seen
as the main source of knowledge for defining drug interactions targeting specifically the elderly.
It is widely used by healthcare professionals and researchers in practice [
By automatically detecting drugs that belong to the Beers Criteria, the ontology, once linked with decision support systems, can be used to support healthcare providers in ensuring that older adults receive safe and efective medical care. In addition, it provides access to accurate and up-to-date information about potentially inappropriate medications. There is currently no tool available in practice that contains and uses Beers Criteria to analyse patient prescriptions that consider patient and prescription parameters related to the criteria.
This paper is structured as follows. Section 2 gives a brief outline of relevant related work for tackling PIMs. Section 3 explains the knowledge acquisition process of the elements of Beers Criteria, which is required for the ontology. Section 4 details the ontology elements and illustrates an ontology conceptual model. In section 5, we describe how the inference rules were defined to detect PIM. An example of how the ontology can be applied in a realistic scenario is given in Section 6. A general discussion in Section 7 concludes the paper.
Studies have shown that the development of computational solutions to tackle PIMs is still an
unresolved issue that requires more work. The majority of approaches used at least one of the
widely used guidelines from the Beers Criteria and/or STOPP&START, which highlight that
these criteria are seen as standard descriptions of PIMs. Most approaches are usually applied to
patients aged 65 years or older, however, in some cases [
There is currently no available solution that can be shared across systems and which
implements the Beers Criteria as rules in some way. Work described in [
The lack of approaches with a shareable knowledge base indicates that sharing knowledge between CDSS is still a problem that needs to be addressed. The various papers highlighted above use the same PIM guidelines (i.e., the Beers Criteria), and thereby a shareable knowledge base for these guidelines would make it possible to improve the quality, exchange and comparison among approaches overall.
The Beers Criteria are not available in a representation that formal reasoning tools can interpret. To obtain a formal representation, we need a taxonomy that captures the main notions, including a hierarchy of groups of medications satisfying diferent criteria (where we use medication and drug interchangeably in this paper): drug-disease and/or drug-syndrome, drug-drug interactions, or drugs to be used with caution. In addition, we need logical axioms and inference rules to define the classification and groups associated with a drug. No formalisation of Beers Criteria can be found in the literature, and this research is hence the first to propose an ontology for Beers Criteria (BC Ontology).
Our BC Ontology is derived from the knowledge captured in the most recent version of the
Beers Criteria [
Figure 1 illustrates how PIMs are listed in [
As shown in Figure 1, the first column lists the PIMs, which can be categorised according to Organ System, Therapeutic Category or Drug(s) in a taxonomic hierarchy. For the example shown, there are three levels: the first level corresponds to the therapeutic drug category Anticholinergics (highlighted in yellow); the second level corresponds to the drug class Firstgeneration antihistamines (highlighted in green); the third level corresponds to the list of drugs that compose the drug class, such as Brompheniramine and Carbinoxamine. Moreover, this column also details if a drug is potentially inappropriate only in specific circumstances. For example, Diphenhydramine is potentially inappropriate only when the administration route is oral (highlighted in pink).
The second column (Rationale) provides information about why the interaction happens, what side efects the interaction may cause for the patient and particular drug situations. To facilitate the visualisation, we highlight the reason in yellow, the side efects in pink and the individual circumstances in blue. For the example shown, the interaction happens because the drug is highly anticholinergic, it is assumed that clearance is reduced with advanced age, and tolerance develops when used as hypnotic. Additional information (e.g., side efects) is given for the clinician to consider, which in this case includes the fact that these drugs could cause risk of confusion, dry mouth, constipation, and other anticholinergic efects or toxicity . Finally, it provides individual circumstances on when using a medication may be appropriate, 1Note that one possible interpretation for such listed drugs is that they interact with the age parameter (drug-age) if given to patients such that their age ≥ 65. which for the case of Diphenhydramine may be situations such as acute treatment of severe allergic reactions. The third column provides the recommendation for the PIMs, which is avoid in this case, for all listed drugs. Next, the forth column provides the quality of evidence for the PIMs, which usually ranges from High, Moderate and Low. Finally, the fith column provides an indication of the Strength of Recommendation, which can be either Strong or Weak.
The BC ontology, when seen as part of a clinical decision support system (CDSS) shown in Figure 2, is designed to assist healthcare professionals in recommending appropriate actions when PIMs are identified. Our CDSS framework integrates multiple reasoning approaches and the BC Ontology constitutes the knowledge base for the inference engines. The inference engine consists of the BC Reasoner for detecting and classifying PIMs, the Drug Alternative Solver for finding alternative drugs to resolve PIMs, and the Rescheduling Solver for minimising drug interactions and determining appropriate prescription timings (usually when there are no suitable alternatives).
To support the inference engines, the BC Ontology has to include all known information on the interactions, recommendations and side efects of drugs related to PIMs. This information is required for any recommendation concerning prescriptions given to the elderly. We have seen in Figure 1 how Beers Criteria are commonly captured in a table with entries in natural language. The first step in formalising PIMs consists in extracting the information from this table into an ontology. This process happens by identifying the elements that the ontology has to consider and the taxonomy hierarchy within the ontology. A taxonomy consists of a hierarchy of classes and subclasses.
To illustrate the process, Figure 3 shows a hypothetical formal representation of DrugA, where all classes are shown as ellipses. Ellipses inside ellipses denote a subclassOf relationship. Drug A is both a drug (subclassOf Drugs) and a drug of a given category (subclassOf of Drug category X). In addition, Drug A is a PIM (inferred subclassOf relationship as shown) within the Beers Criteria.
Let be a patient, be a drug of type Drug A, and be a prescription. The idea conveyed in Figure 3 is that the information shown gives us an inference rule as follows: ℎ (, ) ∧ ℎ ( , ) ∧ ℎ(, ) ∧ ≥ 65 ⇒ () with the interpretation that if has a prescription which contains , and is an older adult, then is a PIM according to the Beers Criteria. The inference rule demonstrates that it is necessary to have a taxonomy composed of classes and elements to define it. The following section details the necessary elements to build the BC Ontology.
Developing the BC ontology involved establishing a collection of classes and subclasses (which as in the example of Figure 3 will be visualised as ellipses contained in multiple levels of ellipses), as well as object properties and data properties. This section will provide a detailed account of each ontology component, outlining its specific features and characteristics to understand its construction thoroughly.
Classes: are the main building blocks of an ontology. Classes are groups or collections of objects that assemble common characteristics, organised hierarchically as a tree, for instance. The main set of classes and subclasses that are the foundation of the taxonomy based on Beers Criteria are: • Beers Criteria is the main interaction class, and is subdivided into five Beers Criteria groups and further refined into several subclasses where interactions are defined. • Drugs is the main class of all drugs that constitute the ontology. • Drug Categories corresponds to the class of therapeutic drug categories, which are groups/classifications of drugs with similar pharmacological properties, mechanisms of action, or therapeutic uses. • Administration Route represents all routes that can exist to administer drugs (e.g., oral, injection or nasal). • Disease denotes the diseases that are relevant in the context of the Beers Criteria. • Exams represents the exams that are relevant in the context of the Beers Criteria • Gender defines the considered patient gender. • Patient represents the class of all patients. • Quality of Evidence establishes the level of the interaction evidence (e.g., high, moderate or low). • Release Drug represents how a drug can be released (e.g., immediate or short-acting). • Strength of Recommendation establishes the level of the interaction recommendation (e.g., weak or strong) • The side efects class represents the possible adverse efects of an interaction.
As previously mentioned, classes are organised in a hierarchical taxonomy. For example, Figure 4 shows how drugs belonging to the class Central nervous system active drugs are represented in a taxonomy. This class consists of two subclasses Anti epileptic and Benszodiazepines. Each of which is in turn composed of its respective drug classes. The drug classes cloBAZam and clonezaPAM are illustrated in an intersection zone, which means that they belong to both subclasses(Anti epileptic and Benzodiazepines).
Data properties: are elements that link instances and literal’s datatype values, such as integer, Boolean, varchar or date. For example, to define a drug dose, the data property hasDailydoseValue links a drug instance with a (float) number. We also need to define the domain and codomain (range) of each data property. For example, hasDailydoseValue has the domain Drugs and the range type float. We describe a few relevant data properties below: • hasDailydoseValue is used to record the total drug dose per day. Its domain is Drugs, and its range is float. • hasDate specifies the date for an exam and/or prescription. Its domain is Prescription and Exams, and its range is date. • hasExamValue is used to record an exam result. Its domain is Exams, and range is float. • hasLenghtDrugTherapy identifies how long the patient takes a specific drug during a hospitalisation. • hasOriginalName is used to record the original name of a drug.
• hasPatientAgeValue is used to record the patient’s age.
• hasDrugType tells the drug type, which can be composed or single. A composed drug has more than one active ingredient. • isCriticalPatient holds if the patient is at a critical level.
• isFirstLineDrug holds if a drug is regarded as the first line of treatment.
Object properties: are the elements that link individuals or classes. In order to establish these relationships, it is necessary to have a subject, a predicate, and an object. For example, if we want to establish a relationship between a subject “prescription” and an object “drug”, we would use the predicate hasDrug. The following list explains each object property defined and relevant to our BC Ontology.
• hasDisease is used to store the diseases a given patient has; • hasDrug is used to associate the prescription with the prescribed drugs; • isDrugOf is the inverse property of hasDrug used to link prescribed drugs with a prescription; • hasExam connects the patient with the exams they have; • hasGender is used to record the gender of a given patient; • hasPrescription is used to associate the patient to prescriptions; • hasQualityofEvidence associates the quality of evidence to a particular interaction; • hasRoute is used to record the administration route of a specific drug; • hasStrengthofRecommendation denotes the strength of recommendation for a specific interaction; • hasTreatmentIndication is used to store the treatment indication of a particular drug. • hasInteractionWith identifies the drug interactions among drugs.
• toRelease is used to record the drug administration release schema.
The outcome of the performed analysis to define the ontology elements is shown in Figure 5, consisting of a conceptual model of the principal classes and relationships between elements required to build the BC ontology. The model has ellipses corresponding to classes, rectangles to denote data properties, and arrows to capture object properties.
The ontology elements were categorised into three main groups to enhance readability: the blue area encompasses elements associated with the patient; the green area represents elements related to drugs and prescriptions; whereas the red area denotes elements specific to PIMs.
The patient class is linked with class Gender, Age, Disease, Lab exam and Prescription by their respective object properties. The prescription class gathers the drugs prescribed for the patient. Hence, this class is linked to the class Drugs. Furthermore, for each prescribed drug, the dose and length of therapy are defined through the data properties has daily dose value and has length drug therapy. Additionally, the administration route and release drug are defined through the object properties has route and to release.
Drugs belong to Drug Categories classes, linked by the construct subclassOf. A prescribed drug may interact with another drug, clinical condition or patient parameters, hence, it will be part of one or more BC subclass(es). All the BC categories are: PIMs (Potentially Inappropriate Medications), DDDS (Potentially Inappropriate Medication Use in Older Adults Due to DrugDisease or Drug-Syndrome Interactions That May Exacerbate the Disease or Syndrome), UWC (Drugs To Be Used With Caution in Older Adults), DDI (Potentially Clinically Important DrugDrug Interactions That Should Be Avoided in Older Adults) and VLKF (Medications That Should Be Avoided or Have Their Dosage Reduced With Varying Levels of Kidney Function in Older Adults). These categories are defined within the Beers Criteria class. For each interaction, the quality of evidence, strength of recommendation and recommendation are defined by their respective object properties. Similarly for the side efect when available.
The definition of these elements allows us to define the rules in the ontology to assess patient prescription and data. More concretely, when incorporated into a CDSS, we can make use of the ontology reasoner to determine if drugs in a prescription are classified as PIM or not.
The inference rules aim to detect if a prescribed drug is classified as PIM, belonging to one or more Beers Criteria categories. Each PIM comprises an annotation property describing why the drug is classified as PIM and object properties to link with the possible side efects, the strength of recommendation and the quality of evidence.
We will detail a drug-disease or drug-syndrome (DDDS) inference rule to comprehend how a drug is classified as PIM. The DDDS PIM rules are composed of four main groups of disease classes: Cardiovascular, Central_nervous_system, Gastrointestinal and Kidney/Urinary tract. For each drug or drug category class, a PIM rule is defined. In Figure 6, the drugs and drug category subclasses of the class Hearth failure (which belongs to class Cardiovascular) are defined. The figure also shows some additional classes and subclasses linked to each PIM. For example, the drug class Cilostazol is linked to the side efect Increase mortality by the object property has side efect . Additionally, this drug has quality of evidence Low, has strength of recommendation Strong and has recommendation Avoid. For all the other drugs or drug categories within Health failure these parameters are also defined, linking classes by object properties to provide additional information on each PIM.
A prescription drug is classified as PIM by an inference rule. The inference rule below demonstrates how a rule was defined for the group of drugs Nondihydropyridine CCBs (cf.
This logical statement says that for an elderly patient with a prescription containing which is either or , and a treatment indication associated with the patient with indication heart failure with reduced ejection fraction, then is classified as _ ℎ _ only if it satisfies the above conditions.
Inference rules were established for all the categories of the Beers Criteria, employing the same logic as demonstrated in the preceding example. In the upcoming section, we will present a comprehensive scenario by integrating patient details and a prescription into the ontology, thereby ofering an illustrative example. We remind the reader that the benefit from the BC ontology comes in the complete context of our CDSS framework shown earlier in Figure 2.
After building the ontology and defining the inference rules for the Beers Criteria classes, it is possible to demonstrate how the ontology would perform over patient data. To this end, we will simulate a fictional scenario illustrated in Figure 7 to demonstrate the relation between classes and various elements, and between drugs and PIM classes assigned through inference rules.
Inside the class Patient (represented with a blue circle), was created the individual Tom. This individual is linked to the individual M(Male) in the class Gender by the object property hasGender and with the individual P1 in the class Prescription by object property hasPrescription. Tom is aged 75 (e.g., the data property hasPatienAgeValue is linked to an integer value 75). Moreover, this patient has a history of falls. Hence he is linked by the object property hasDisease to the individual P1_History_of_falls, which belongs to the class with the same name and to the class Disease.
The individual P1 is linked with four individual drugs by the object property hasDrug. The four individuals belong to the class Drugs. The individual P1_ Metoclopramide is a Metoclopramide drug, a subclass of Prokinetic Agents. The individual P1_Triazolam belongs to the Benzodiazepines drug class and, P1_Codeine and P1_Morphine belong to the drug class Opiate Agonists. All the three belong to the drug category class Central nervous system active drugs and are administered by injection. Hence, they are linked by the object property hasRoute to the individual P1_Inject, which belongs to the class Administration Route.
After defining the details above for patient Tom, the ontology rules were executed over the ontology and patient data to check if problems in the prescribed drugs could be identified. The individual drugs are linked to four Beers Criteria classes. These classes are divided into two main superclasses PIM and DDI. The PIM_Metoclopramide is a subclass of Gastrointestinal and PIM_Benzodiazepines is a subclass of the Central nervous system, both of which belong to class PIM. The DDI subclass, Opioids/Benzodiazepines means an interaction between the drug category Opioids and Benzodiazepines. The CNS_Active_Drugs/CNS _Active_Drug means an interaction between drugs from the same drug category CNS_Active_ Drugs.
The DDI interactions happen between two or more drugs as illustrated in Figure 8. The red double-headed arrow represents the object property hasInteractionWith, meaning the interaction is bidirectional. For example, the individual P1_Triazoalm interacts with P1_Codeine and P1_Morphine, and P1_Codeine interacts with P1_Morphine. The PIM drugs assertion was obtained by inference rules that compose the ontology. For each PIM class, a rule was defined. Therefore, we will detail the inference rules for this example to understand how the ontology classified these individual drugs as PIM.
In the following, let denote a patient, a prescription, a drug of type Metoclopramide, and an integer. The PIM_Metoclopramide inference rule is defined as follows: (ℎ (, ) ∧ ℎ ( , ) ∧ ()∧ ℎ (, ) ∧ ≥ 65) ⇒ _ () The logical expression formulated for the PIM_Metoclopramide defines that for an elderly ⇒ ∀,
ℎ ℎ( _ _
3) ∧ ℎ (, ) ∧ ≥ 65 _ _ _ _ _ _ , ) ∧ ℎ ℎ( _ ( _ ( )∧ )∧ , )
According to this rule, for an elderly patient with prescription containing distinct drugs 1, 2 and 3 of type Central_nervous_ system_active_drugs, then each of the three drugs has a (bidirectional) drug-drug interaction (DDI) with each other as defined in the object property hasInteractionWith and these drugs belong to the PIM category DDI_CNS_Active_Drugs CNS_Active_Drugs.
Through the integration of patient data with the ontology, this example showcases how we can utilise the ontology to detect PIMs. Additionally, the ontology can be integrated with a Clinical Decision Support System (CDSS) (cf. Figure 2) or other ontologies to enhance its usability and facilitate the sharing of knowledge. It also keeps the knowledge base separate, and makes it easier to accommodate changes to the knowledge associated to BC (e.g., through new revised criteria), without impacting on the remaining components and reasoning engines.
Digital solutions can be introduced to promote medication safety by facilitating evidenceinformed medication use, reducing the incidence of harmful medication errors, and improving the eficiency of healthcare systems in practice [ 16]. PIMs in the elderly are a global concern that must be addressed to avoid adverse reactions to medications and improve quality of life. Here, we introduced a novel ontology-based approach to capture Beers Criteria which can be used to detect and subsequently react to inappropriate prescribing in those over 65.
Our ontology can be used to detect drug interactions and consequently support clinical decision-making. Nevertheless, this is just one step of the decision process. Further recommendation steps include preferred alternatives with equal/similar therapeutic value, revised timed schedules for medications to avoid interactions when no alternative is present, as well as revision of medications to check whether there is still a therapeutic need for certain medications over time. The latter are part of the CDSS framework shown in Figure 2, which makes use of SMT solvers such as Z3, and have been presented in some of our earlier work. The main focus of this paper was the description of the complex BC Ontology itself.
Bowles is partially supported by Austrian FWF Meitner Fellowship M-3338 N. 8 (2020) e14130. [12] E. Frutos, M. Kakazu, M. Tajerian, A. Gaiera, L. Rubin, C. Otero, D. Luna, Clinical decision support system for pim in elderly patients: Implementation and initial evaluation in ambulatory care, Studies in Health Technology and Informatics 294 (2022) 475–479. [13] E. G. McDonald, P. E. Wu, B. Rashidi, A. J. Forster, A. Huang, L. Pilote, L. Papillon-Ferland, A. Bonnici, R. Tamblyn, R. Whitty, et al., The medsafer study: a controlled trial of an electronic decision support tool for deprescribing in acute care, Journal of the American Geriatrics Society 67 (2019) 1843–1850. [14] S. Ghibelli, A. Marengoni, C. D. Djade, A. Nobili, M. Tettamanti, C. Franchi, S. Caccia, F. Giovarruscio, A. Remuzzi, L. Pasina, Prevention of inappropriate prescribing in hospitalized older patients using a computerized prescription support system (intercheck®), Drugs & aging 30 (2013) 821–828. [15] T. M. García-Caballero, J. Lojo, C. Menéndez, R. Fernández-Álvarez, R. Mateos, A. GarciaCaballero, Polimedication: applicability of a computer tool to reduce polypharmacy in nursing homes, International psychogeriatrics 30 (2018) 1001–1008. [16] P. Jia, L. Zhang, J. Chen, P. Zhao, M. Zhang, The efects of clinical decision support systems on medication safety: an overview, PloS one 11 (2016).