=Paper=
{{Paper
|id=None
|storemode=property
|title=Building a Drug Ontology based on RxNorm and Other Sources
|pdfUrl=https://ceur-ws.org/Vol-1061/Paper7_vdos2013.pdf
|volume=Vol-1061
|dblpUrl=https://dblp.org/rec/conf/icbo/HannaJBH13
}}
==Building a Drug Ontology based on RxNorm and Other Sources==
https://ceur-ws.org/Vol-1061/Paper7_vdos2013.pdf
Building a Drug Ontology based on RxNorm and Other Sources
Josh Hanna,* Eric Joseph, Mathias Brochhausen, and William R. Hogan
Division of Biomedical Informatics, University of Arkansas for Medical Sciences, Little Rock, Arkansas, USA
ABSTRACT requires companies to report to the Food and Drug Admin-
We
built
the
Drug
Ontology
(DrOn)
to
meet
the
requirements
of
our
istration (FDA). RxNorm associates each NDC with a drug
comparative-‐effectiveness
research
use
case,
because
existing
artifacts
had
flaws
too
fundamental
and
numerous
to
meet
them.
However,
one
product via the RXCUI. Although our requirement is to
of
the
obstacles
we
faced
when
creating
the
Drug
Ontology
(DrOn)
was
have a comprehensive, historical list of NDCs, RxNorm
the
difficulty
in
reusing
drug
information
from
existing
sources.
The
maintains only currently active NDCs in its current release.
primary
external
source
we
have
used
at
this
stage
in
DrOn’s
develop-‐
ment
is
RxNorm,
a
standard
drug
terminology
curated
by
the
National
So tracking all NDCs and the RXCUIs with which they
Library
of
Medicine
(NLM).
To
build
DrOn,
we
(1)
mined
data
from
have been associated over historical releases of RxNorm is
historical
releases
of
RxNorm
and
(2)
mapped
many
RxNorm
entities
key to building DrOn.
to
Chemical
Entities
of
Biological
Interest
(ChEBI)
classes,
pulling
rele-‐ Moreover, NDCs are often lost with no explanation when
vant
information
from
ChEBI
while
doing
so.
We
built
DrOn
in
a
modular
fashion
to
facilitate
simpler
extension
and
an RXCUI is retired, especially in releases of RxNorm prior
development
of
the
ontology
and
to
allow
reasoning
and
construction
to 2009. This situation necessitates careful tracking to en-
to
scale.
Classes
derived
from
each
source
are
serialized
in
separate
sure that all valid NDCs (and, indeed, any useful infor-
modules.
For
example,
the
classes
in
DrOn
that
are
programmatically
mation) associated with a retired RXCUI can be associated
derived
from
RxNorm
stored
in
a
separate
module
and
subsumed
by
classes
in
a
manually
built,
realist,
upper-‐level
module
of
DrOn
with
with the most recent RXCUI that refers to the same entity.
terms
such
as
‘clinical
drug
role’,
‘tablet’,
‘capsule’,
etc.
While other drug information sources exist, none of them
was sufficient. Our requirements include (1) a historically
1 INTRODUCTION comprehensive list of NDCs, (2) correctness with respect to
An ontology of drugs could be useful for a variety of pur- pharmacy and biomedical science, (3) logically consistent,
poses, such as comparative effectiveness research (Olsen, correct axioms that do not entail untrue or inconsistent in-
2011), clinical decision support (Broverman, 1998; Sperzel, ferences, and (4) interoperability with other ontologies for
1998; Kim, 2001), and clinical data warehousing and inte- translational science. In previous work, we analyzed
gration (Broverman, 1998; Nelson, 2011; Palchuk, 2010; RxNorm, the National Drug File – Reference Terminology,
Parrish, 2006; Kim, 2001), among others. At present, no SNOMED CT, Chemical Entities of Biological Interest
existing resource was sufficient for our use cases in these (ChEBI), an OWL conversion of the Anatomical and Thera-
domains (see our sister paper (Hogan, 2013)), and therefore peutic Chemical classification system, DrugBank, Phar-
we decided to build the Drug Ontology (DrOn). Minimally, mGKB, and other sources (Hogan, 2013) and found that
no existing resource contains in its current version a histori- none of them met these requirements.
cally comprehensive list of National Drug Codes (NDCs). In this paper, we describe how we build DrOn from his-
RxNorm (Nelson, 2011)—a standard drug terminology torical releases of RxNorm, while navigating these pitfalls.
maintained by the U.S. National Library of Medicine In addition, during the build process, we map drug ingredi-
(NLM)—includes normalized names and relationships ex- ents from RxNorm to the Chemical Entities of Biological
tracted from several proprietary drug knowledge bases. Interest (ChEBI) ontology (de Matos, 2010). As a result,
Because of (1) the large amount of drug information main- we import hundreds of ChEBI classes and their associated
tained within RxNorm, (2) the fact that it is freely available, URIs, labels, etc. into DrOn.
and (3) the fact that much of it is available under a permis-
sive license, RxNorm is a good candidate for a source of 2 METHODS
information to create a formal drug ontology. The overall workflow of the extraction and translation pro-
RxNorm is focused primarily on prescription and over- cess has three main steps:
the-counter drugs that are currently available in the United 1. Mining RxNorm for relevant entities, including infor-
States. It uses Concept Unique Identifiers called RXCUIs to mation found only in older releases.
catalog and relate information. 2. Extracting, Transforming, and Loading (ETL) the data
At this stage of DrOn development, we are interested in mined from RxNorm into a normalized Relational Da-
the ability to query for National Drug Codes (NDCs). The tabase Management System (RDBMS).
NDC is a unique identifier that the Drug Listing Act of 1972 3. Translating the normalized RDBMS into an OWL 2.0
artifact.
* To whom correspondence should be addressed: jhanna@uams.edu
1
Hanna et al.
Each of these three steps is further subdivided into sub- 2.1.2 RXCUI Provenance
steps that we explain in detail below.
Tracking entities within RxNorm requires tracking the
2.1 Mining RxNorm RXCUIs to which they are attached. This can be a difficult
We first download the raw RxNorm data files directly from task. Any RXCUIs that have been entered in error are re-
the NLM website, specifically the UMLS (or Unified Medi- tired. Additionally, if two RXCUIs refer to the same entity,
cal Language System) Terminology Services (UTS) site they are consolidated and either one of them is retired while
(U.S. National Library of Medicine, 2011) and import them the other remains or a new RXCUI is created and both older
into a locally hosted RDBMS using the scripts provided by RXCUIs are retired. Prior to the April 2009 release of
the NLM. Additionally, to support maintenance of compre- RxNorm, no comprehensive list of retired RXCUIs was
hensive information over time, we created and maintain two provided. Furthermore, the reasons for retirement are not
additional tables that store all the information that we ex- always well-documented, making it difficult to distinguish
tract from each release of RxNorm (a subset of all the in- between RXCUIs that have been retired because they are
formation). We describe these tables in detail below (sec- nonsense and ones that have been replaced or merged. For
tions 2.1.3 and 2.1.4). instance, as of this writing, there are 40 RXCUIs with 210
Currently, we include information from every version of associated NDCs that are no longer contained in the most
RxNorm released between June, 2008 and February, 2013 in recent release of RxNorm, however, there is no record of
DrOn. The reason is that the June, 2008 release was the why these RXCUIs were removed.
first one that includes RxNorm-curated NDCs.
It should be noted that we use only information curated 2.1.3 Extraction of National Drug Codes (NDCs) and
within RxNorm and not any information from its sources related RXCUIs
directly, and thus our overall process is allowable under the To facilitate the tracking of NDCs, we have created an addi-
UMLS license (all content reused in DrOn is Level 0). tional table, NDC_COMP, that contains a comprehensive
list of all RxNorm-curated NDCs from all releases of
2.1.1 RxNorm Files RxNorm since June 2008 (when they first appeared) and
The next step is to extract all relevant information from the their corresponding RXCUIs. To generate this table, we
files downloaded from the UTS site. RxNorm comes as a set parse the RXNSAT.RRF data file contained in each release
of nine Rich Release Format (RRF) files, each of which of RxNorm. Any entry in the file whose source is RxNorm
contains a specific subset of the total information. However, and is annotated as being an NDC is extracted from the file,
we do not use all nine files in our build process. along with its associated RXCUI, and imported into our
We process RXNSAT.RRF, RXNCONSO.RRF, NDC_COMP table. We also store the version from which
RXNCUI.RRF, and RXNCUICHANGES.RRF, each NDC was mined, which is parsed from the
RXNSAB.RRF. Table 1 shows the information we mined RXNSAB.RRF data file as mentioned in Section 2.1.1.
from each file.
2.1.4 Tracking Provenance
File Extracted Information The second of the two additional tables is a master conver-
RXNSAT.RRF NDCs and RXCUIs sion table, DEPRECATED_RXCUIS, which we use to track
RXNCONSO.RRF RXCUI attributes the current status of each retired RXCUI. This table contains
RXNCUI.RRF retired RXCUIs with prove- two fields: old_rxcui and new_rxcui. The old_rxcui field
nance contains a retired RXCUI, and the new_rxcui field contains
RXNCUICHANGES.RRF RXCUI provenance the current RXCUI to which the retired RXCUI’s infor-
RXNSAB.RRF RxNorm version infor- mation is now associated. The new_rxcui field may also
mation contain a status code if the retired RXCUI’s information is
Table 1: The RxNorm files and the information mined from each. unable to be tracked because it was entered in error or split
into multiple new RXCUIs. These special status codes are
There are four different term types in RXNCUI.RRF that “ERROR” for RXCUIs that have been entered in error and
are relevant to DrOn. They are: (1) Semantic Clinical Drug “S_RXNCUI” for RXCUIs which have been split. Because
Forms (SCDFs), (2) Semantic Clinical Drugs (SCDs), (3) RxNorm does not document why an erroneous RXCUI was
Semantic Branded Drugs (SBDs), and (4) Ingredients (IN). entered in error, we are unable to do further processing on
RxNorm treats NDCs as attributes of an SCD or SBD rather them or their associated information. For the RXCUIs
than a separate term type. which are split, it may be possible to track some of their
associated information, but it is not always clear which in-
2
Building a Drug Ontology based on RxNorm and Other Sources
formation belongs to which child RXCUI and this issue entities and ChEBI annotations were assumed to be refer-
requires manual intervention at present. ring to the same entity type and thus the ChEBI URIs were
used in DrOn. Three different annotation types from ChEBI
Our DEPRECATED_RXCUIS table is updated with each
are used in the mapping process: label, related_synonym,
release of RxNorm through the following procedure:
and exact_synonym. To date, we import into DrOn ~750
1. First, we extract any RXCUIs from the comprehensive classes (including URI and label and other annotations)
NDC_COMP table, built in Section 2.1.3, that can no from ChEBI: roughly 500 matches were found via label,
longer be found in the RXNCONSO.RRF file being im- 250 were found via related_synonym, and only two were
ported. We then import these RXCUIs into the found via exact_synonym. Many of the ingredients found in
old_rxcui column of our DEPRECATED_RXCUIS ta- RxNorm are extracts of various plants, e.g. ginger extract,
ble. Because the RXNCONSO.RRF file contains all cur- which we would not expect to find in ChEBI.
rent RXCUIs, any RXCUIs that meet the above criteria Somatropin (also known as somatotroin or human growth
must have been retired. hormone) was erroneously associated with the ChEBI role
‘growth hormone’. This error, once noticed, was fixed. The
2. Next, using the RxNorm-curated RXNCUI table, we
term is now mapped to the Protein Ontology URI that repre-
update all entries in the new_rxcui column. The
sents the protein molecule somatotropin.
RXNCUI table contains a cui1 field containing a retired
We assigned a DrOn URI to every ingredient that was not
RXCUI, a cui2 field containing the RXCUI into which
found in ChEBI via this process.
the retired RXCUI’s information has been merged, and
a cardinality column contains the number of RXCUIs 2.3 ETL into a Normalized Format
into which the information has been merged. Any There are five RxNorm entity types we were initially inter-
RXCUI that has been entered in error is indicated by an ested in pulling from RxNorm. These are the following:
entry in which the value of the cui1 field is equal to the ingredient, clinical drug form, clinical drug, branded drug,
value of the cui2 field. Additionally, any entry with a and national drug code (NDC). Additionally, we wanted to
cardinality greater than 1 indicates that the RXCUI has represent a number of ingredient dispositions. Figure 1
been split. These are indicated in our table by setting shows these six entity types and the relationships between
the new_rxcui entry to “ERROR” and “S_RXNCUI”, them. They are described in some detail next. It should be
respectively. As of this writing, 768 RXCUIs and 3,484 noted that the entities the NDC class represent are not the
associated NDCs are reported by RxNorm to have been codes themselves, but instead the packaged drug products
entered in error and are therefore not included in DrOn. that the NDCs represent. Additionally, every DrOn entity
Additionally, 187 RXCUIs and 3,126 associated NDCs that corresponds to a RxNorm entity is annotated with the
have been split. Both these RXCUIs and NDCs have al- corresponding RXCUI.
so been left out of DrOn (for the time being) due to the
difficulty of determining which information from the
parent RXCUI belongs to which child RXCUI.
3. Finally, we compute the transitive closure, associating
each RXCUI with the latest RXCUI that refers to the
same entity with no intervening steps in our
DEPRECATED_RXCUIS table. Because this table is
updated with each release of RxNorm, occasionally an
RXCUI in the new_rxcui field is retired. In such situa-
tions, the new_rxcui field is updated as described in
Step 2, and a new row in the table is created with the
newly-retired RXCUI set as the old_rxcui, and the
new_rxcui field is set to match the updated new_rxcui Fig. 1: The entity types of DrOn and their relationships as stored in the
from the original entry. normalized format
2.2 Mapping to ChEBI 2.2.1 Entity types
The process maps ingredients (IN entity type) extracted
The ingredient entities represent the types of molecules that
from RxNorm to ChEBI entities where possible. We ac-
are present in a drug product and have an active biological
complish this step through a simple Java console application
role. The URIs of ingredients, where possible, are taken
(that we built) that compares the labels of ingredients pulled
from the Chemical Entities of Biological Interest (ChEBI)
from RxNorm with annotations in ChEBI. Any exact
ontology as described above. Examples of these include
matches between the names or synonyms of RxNorm IN
3
Hanna et al.
acetaminophen, sulfur, and ephedrine. There are 7,848 by the more specific nature of DrOn’s dispositions as com-
unique ingredients in DrOn. pared to ChEBI’s more general calcium channel blocker.
The disposition entities represent dispositions that mole- The Clinical Drug Form (CDF) entities represent a type
cules bear (see Hogan, 2013). There are, as of now, six mo- of drug product, dose form (e.g. drug tablet), and, often, the
lecular dispositions in DrOn. They are: intended route of administration (e.g. oral ingestion) without
brand or strength information. These correspond to SCDFs
1. non-activating competitive beta-adrenergic receptor
in RxNorm. Examples of CDFs include estradiol transder-
binding disposition (i.e., beta-adrenergic blockade)
mal patch, iodine topical solution, and menthol crystals.
2. function-inhibiting hydrogen/potassium adenosine tri-
There are 14,035 unique CDFs in DrOn.
phosphatase enzyme (H+/K+ ATPase) binding disposi-
The Clinical Drug (CD) entities represent drug products
tion (i.e., proton-pump inhibition)
with specific dosage/strength/form information. They are
3. function-inhibiting L-type voltage-gated calcium chan-
related to the CDF by an is-a relationship. For example,
nel binding disposition (i.e., a subtype of calcium-
every aspirin 325 MG enteric coated tablet (CD) is a aspi-
channel blockade)
rin enteric coated tablet (CDF). DrOn contains 34,560 CDs.
4. function-inhibiting vitamin K epoxide reductase binding
The Branded Drug (BD) entities represent brand-name
disposition (i.e., a type of Vitamin K antagonism)
drug products with specific dosage/strength/form infor-
5. function-inhibiting Na-K-Cl cotransporter 2 (NKCC2)
mation. The drug products that BDs represent are related to
binding disposition (i.e., NKCC2 inhibition)
the products that CDs represent by an is-a relationship.
6. function-inhibiting T-type calcium channel binding dis-
There are 21,248 unique BDs in DrOn.
position (i.e., another subtype of calcium-channel
The National Drug Code (NDC) entities represent a drug
blockade)
product and its packaging. These entities are distinct from
These six dispositions were chosen based on their biolog- entities represented by BDs or CDs, instead containing
ical importance and relevance to ongoing comparative effec- some number of instances of drug products represented by
tiveness research at the University of Arkansas for Medical CDs/BDs, for example a 100-tablet bottle of aspirin 325 mg
Sciences. There is no direct correspondence between DrOn tablets. There are 390,813 unique NDC entities in DrOn.
dispositions and RxNorm, because by design RxNorm lacks
information about mechanism of action. Instead, the rela- DrOn Entity Type RxNorm Entity Type
tionships between DrOn dispositions and ingredients was CDF SCDF
mined from ChEBI, although ChEBI treats the same realiz- CD SCD
able entities that we represent here as roles (see Hogan, BD SBD
2013 for more details). Table 2 shows the associated Ingredient IN
ChEBI role from which the ingredient relationships for the NDC SCD or SBD Attribute
three dispositions were mined. The other three dispositions Table 3: The associated RxNorm entity type for each DrOn entity type
not in the table were curated manually by the authors. except disposition.
DrOn Disposition ChEBI Role
2.3.2 RDBMS design
non-activating competitive beta- beta-
adrenergic receptor binding disposition adrenergic The RDBMS design representing the normalized format of
antagonist the entity types described above is simple. There are 5 core
function-inhibiting hydrogen/potassium proton pump tables, one for each entity type. These are as follows: clini-
adenosine triphosphatase enzyme inhibitor cal_drug_form, clinical_drug, branded_drug, ndc, ingredi-
(H+/K+ ATPase) binding disposition ent, and disposition.
function-inhibiting L-type voltage- calcium chan- Additionally, there are two tables storing provenance in-
gated calcium channel binding disposi- nel blocker formation from RxNorm, such as the version of RxNorm in
tion which each RxCUI was found. These are rxcui and rxnorm.
Table 2: The ChEBI roles used to mine DrOn disposition-ingredient rela- These are completely separate from the core entity tables to
tionships allow for incorporation of other data.
Many-to-many tables representing the relationships be-
Function-inhibiting T-type calcium channel binding dis- tween the various entities are omitted in the interest of brev-
position was included because we erroneously associated ity. However, all of the relationships shown in 1 are also
ethosuximide and function-inhibiting L-type voltage-gated represented in RDBMS.
calcium channel binding disposition. This error was not due
to any particular oversight of ChEBI but an artifact caused
4
Building a Drug Ontology based on RxNorm and Other Sources
2.3.2 ETL process Currently, DrOn has five different modules: dron-full,
dron-chebi, dron-rxnorm, dron-pro, and dron-upper.
The ETL process is done in four major steps:
The dron-full module is simply a connector that imports
1. First, we initialize the rxcui and rxnorm tables. This
the other modules. It is so named on the assumption that
includes mapping every deprecated RXCUI to the most
certain subsets of the modules may prove useful enough to
recent RXCUI that identifies the same object, either to
warrant lighter versions of the ontology.
an RXCUI from the current set or another deprecated,
The dron-chebi module contains all of the annotations for
but not entered in error, RXCUI.
the ingredients mapped to ChEBI (as described in Section
2. Next, we initialize the ndc table. This primarily in-
2.2). It contains everything imported from ChEBI.
volves copying all the NDCs found in the mining pro-
The dron-rxnorm module contains all of the information
cess (without the duplication caused by storing NDCs
mined from RxNorm, which, at this point of the ontology’s
multiple times during the mining process) and associat-
development, is the bulk of DrOn’s information. It includes
ing them with the relevant RXCUI.
the NDCs, though we plan to split the NDCs from the rest
3. Next, we create the ingredients, CDFs, CDs, and BDs
of the RxNorm module in future work.
from the associated RxNorm type. This includes main-
The dron-pro module includes everything imported from
taining the proper relationships between the various en-
the Protein Ontology (PRO). At present, it is very small and
tities (e.g. associating the correct ingredients with each
only contains the ‘protein’ and ‘somatotropin’ classes from
CDF).
PRO. As stated above, we imported these classes to repre-
4. Finally, we associate each NDC with the appropriate
sent somatotropin as a drug ingredient.
CD or BD. This primarily involves following the prov-
The dron-upper module contains the hand-created upper
enance trail of RXCUIs provided in step 1.
level ontology that the other modules are mapped on to (see
2.4 Creating the OWL 2.0 Artifact Hogan, 2013).
We use the OWLAPI 3.4.3 (Horridge, 2011), Scala 2.10 This modularization brings two major benefits: develop-
(Odersky, 2004), and Slick 1.0.0 (Typesafe, 2013) to extract ment simplicity and increased scalability. By creating logi-
the entities from our internal representation and transform cal divisions and well-defined interfaces between the mod-
them into an OWL artifact. This process is subdivided into ules, we can more easily maintain each module separately
the following steps: without significantly affecting the other modules. Addition-
1. Extract the ingredients, using ChEBI URIs where ap- ally, as each module grows in size, we can shard the pro-
propriate. cessing and creation of the ontologies to different servers,
2. Extract the dispositions and associated them via the making scaling the process simpler.
bearer_of relation to the one or more ingredients.
3. Extract the clinical drug forms and associate them via 3 DISCUSSION
the has_proper_part relation to the one or more ingre- We developed an ontology, DrOn, that contains information
dients. programmatically derived from three different sources
4. Extract the clinical drugs and assert they are a subclass (RxNorm, ChEBI, and PRO) during its build process. Be-
of the appropriate clinical drug form. cause it is derived from general-purpose resources, we be-
5. Extract the branded drugs and assert that they are a sub- lieve DrOn can serve many use cases beyond our current
class of the appropriate clinical drug. ones (although this conjecture requires further research).
6. Extract the NDCs and assert that they are related to one We plan on adding additional sources in the future to main-
branded drug or one clinical drug via the tain current information in DrOn, with more immediate
has_proper_part relation. plans to include information from Structured Product La-
bels. As such, we built our internal representation to main-
This ordering of the steps is deliberate. Each step de- tain provenance information of the sources separately, en-
pends on one or more previous steps. suring that we can both track the provenance of the various
Since the RDBMS structure defined above represents the entities as the ontology develops and add new sources with-
entities and their relationships already, this process is fairly out adversely affecting the existing ontology.
straightforward. DrOn follows OBO Foundry guidelines and is currently
listed on the OBO Foundry website as a candidate ontology.
2.4.1 Modularization In additional to the mining detailed above, DrOn imports
BFO 1.1 and includes terms MIREOTed from the Relation-
The ability to incorporate additional sources of information
ship Ontology and BFO 2.
has been a key requirement for the build process. To help
The development site and issue tracker for DrOn can be
facilitate this, we developed DrOn in a modular fashion.
found at https://bitbucket.org/uamsdbmi/dron. The perma-
5
Hanna et al.
nent URL for DrOn is ACKNOWLEDGEMENTS
http://purl.obolibrary.org/obo/dron.owl. This work was supported by award number UL1TR000039
Our primary, driving use case was support for Compara- from the National Center for Advancing Translational Sci-
tive Effective Research. Author WRH was part of a re- ences, award R01GM101151 from the National Institute for
search team wherein a student had to manually identify all General Medical Science, and the Arkansas Biosciences
drug products that contain acetaminophen historically. We Institute, the major research component of the Arkansas
built a web application that uses DrOn to support this use Tobacco Settlement Proceeds Act of 2000. This paper does
case; users can search for all NDCs that either contain a not represent the views of NCATS, NIGMS, or NIH.
specific ingredient or contain an ingredient that realizes a
specific disposition. This web application is accessible at REFERENCES
http://ingarden.uams.edu/ingredients.
Nelson, S.J., Zeng, K., Kilbourn, J., Powell, T., &Moore, R.
Future work includes addressing limitations in the current
(2011). Normalizied names for clinical drugs: RxNorm at 6
process. One of the more egregious examples is the lack of a years. Journal of the American Medical Informatics Associa-
link from the various drug products to their dose forms (e.g., tion: JAMIA, 18(4), 441 - 448
drug capsule). Nearly all of the most common dose forms U.S. National Library of Medicine (2011). RxNorm Retrieved
are already in the upper level of the ontology (dron-upper April 24, 2013, from http://www.nlm.nih.gov/research/umls/rxnorm/
module), but the CDFs are not properly related to them. de Matos, P., Alcántara, R., Dekker, A., Ennis, M., Hastings, J.,
This is due to (1) time constraints and (2) the dubious onto- Haug, K., Spiteri, I., Turner, S., and Steinbeck, C. (2010).
logical nature of some of the dose forms found in RxNorm. Chemical Entities of Biological Interest: an update. Nucl. Acids
For example, ‘inhaler’ does not refer to the form of the drug Res., 38, D249–D254.
but instead to its container (which also serves the role of Horridge, M., Bechhofer, S. (2011). The OWL API: A Java API
for OWL Ontologies. Semantic Web Journal, 2(1), 11 – 21
drug delivery device). But the form of the drug itself is a
Odersky, M., Altherr, P., Cremet, V., Dragos, I., Dubochet, G.,
solution or suspension contained in the inhaler. Note that
Emir, B., McDirmid, S., Micheloud, S., Mihaylov, N., Schinz,
the presentation form in this case (e.g., solution) differs M., Stenman, E., Spoon, L., Zenger, M. (2004). An Overview
from the administration form (e.g., aerosol). of the Scala Programming Language, Technical Report LAMP-
Another issue is the lack of a full logical definition for REPORT-2006-001
some of the terms. For instance, only a small subset of the Typesafe (2013), Slick Retrieved April 24, 2013, from
parts of each drug product is defined. A clinical drug form http://slick.typesafe.com/
contains information about its dose form, its route of admin- Broverman, C., Kapusnik-Uner, J., Shalaby, J., & Sperzel, D.
istration, and its active ingredients. As of the writing of this (1998). A concept-based medication vocabulary: an essential
paper, the only one of these that is represented in the ontol- requirement for pharmacy decision support. Pharmacy practice
ogy as classes are the active ingredients, though dose forms management quarterly, 18(1), 1-20.
Palchuk, M. B., Klumpenaar, M., Jatkar, T., Zottola, R. J., Adams,
are mostly represented. Even these, however, are still not
W. G., & Abend, A. H. (2010). Enabling Hierarchical View of
fully developed, generally lacking any class restrictions.
RxNorm with NDF-RT Drug Classes. AMIA Annual Symposi-
Additionally, a clinical drug contains dosage information um proceedings, 2010, 577-581.
and branded drugs have brand information. Neither of the- Parrish, F., Do, N., Bouhaddou, O., & Warnekar, P. (2006). Im-
se is represented in the ontology. plementation of RxNorm as a Terminology Mediation Standard
The final issue with the process is the need for manual in- for Exchanging Pharmacy Medication between Federal Agen-
teraction. Although each step within in the process is auto- cies. AMIA Annu Symp Proc, 1057.
mated, they are not tied together in a coherent way. We ex- Olsen, L., Grossman, C., & McGinnis, J. M. (2011). Learning
pect that some manual intervention will always be needed as What Works: Infrastructure Required for Comparative Effec-
we continue to mine updated information from these tiveness Research: Workshop Summary: The National Acade-
sources, but there is significant room for improvement in mies Press.
Sperzel, W. D., Broverman, C. A., Kapusnik-Uner, J. E., & Schle-
connecting the various segments of the overall process flow
singer, J. M. (1998). The need for a concept-based medication
and fully automating the less ontologically nebulous steps.
vocabulary as an enabling infrastructure in health informatics.
Since DrOn is already large, and will likely increase in Proceedings AMIA Annual Symposium. 865-869.
size as we incorporate more sources and as more drug prod- Kim, J. M., & Frosdick, P. (2001). Description of a drug hierarchy
ucts are manufactured, we expect that we will run into diffi- in a concept-based reference terminology. Proc AMIA Symp,
culties managing generation of and reasoning over the on- 314-318.
tology. One potential solution we intend to investigate is to Hogan, W. R., Hanna, J., Joseph, E., Brochhausen, M. (2013).
reason over the modules individually and combine the re- Towards a Consistent and Scientifically Accurate Drug Ontolo-
sults. We also intend to create more manageable subsets of gy. ICBO 2013 Conference Proceedings
DrOn, which should allow users to work with only the por-
tions of DrOn that they need for a particular use case.
6