Our use case for maintenance of the Drug Ontology includes a semi-automated, daily process capable of importing new, relevant information from a variety of linkable resources, using fast and flexible algorithms with full access to all data. Structured Product Labels contain linkable information regarding FDA approved drug products and the drug packages in which they are sold, as well as ingredients and metadata about the drugs. We created an Application Programming Interface for SPLs using Scala, which will run on any implementation of the Java Virtual Machine (JVM) and is freely available through an open-source license for any noncommercial use.
We are using Structured Product Labels (SPL) from the Food and Drug Administration (FDA) to capture new drug and related entities for representation in the Drug Ontology (DrOn). The reason is that manufacturers must submit an SPL for all new drugs approved in the United States, and thus this information is “directly from the source”. It is also much richer than what is available in drug terminologies such as RxNorm. This paper describes our processes and the software we are developing to support them for extracting information from SPLs to update DrOn as new drug products come into existence.
SPLs are machine-readable files, submitted-to and released-by the FDA, containing prescription drug labeling and product metadata, such as National Drug Codes (NDCs) and drug product ingredients. They are available as full “current revision” releases, and monthly, weekly, or daily updates from the DailyMed website at http://dailymed.nlm.nih.gov. Each archive release contains individual archives. Each individual archive contains one XML file and may contain zero or more “.jpg” image files, which are referenced by the XML file.
SPLs have been found useful linking active ingredients
and chemical entities
Recent work
In addition to the need to drive DrOn maintenance, we are aware that SPL files are created by a large and diverse user base in industry and submitted to the FDA, so we have also included the capability to write SPL documents. Although one free tool for creating and editing SPL files exists (“SPL XForms”), we discuss here our motivations for creating a new tool.
Our implementation is an Application Programming Interface (API) for SPLs (SPL-API) which we use to update DrOn each day using the “daily updates” from Dailymed.
SPL-API also includes features for downloading and parsing full releases and monthly and weekly updates.
Thus, the goal of this work is to create a generally useful open-source parser and writer for SPL XML files, and to use it within a larger system to update DrOn with applicable classes and their relationships, enabling additional data to be linked by other processes. As a result DrOn will be continuously updated with new drug products as they are approved. 2
The DrOn support system must Extract, Transform, and
Load (ETL) data from a variety of sources in order to
automatically rebuild the “lower ontology” containing specific
drug products from the latest sources. A DrOn Builder has
been previously implemented
Our use case requires full access to all data in available resources and flexible server-side processing, preferring a local library over a connected service for both processing speed and algorithmic flexibility.
LinkedSPL provides SPL content for prescription and over-the-counter drugs, and is updated weekly. It can be accessed through a SPARQL endpoint to acquire the freetext contained in any “section” of the SPL file, which is defined by the “<section>” tag-set. Although the LinkedSPL software artifacts are freely available, and may be used locally, they are unable to report included label image files or a link to them. LinkedSPL also only parses prescription and OTC files, leaving out the “Remainder” labels (which include data on vaccines and some medical devices) and the “Animal” labels. Additionally, DrOn is not currently using RDF technologies (other than serialization of OWL into RDF), so we seek to avoid the complexity of adding an intermediate representation to the system.
A browser-based editor (“SPL XForms”) for SPL format
XML files is also available
Software was written to survey all XML elements and their attributes and relationships. Survey data will be available online (see section 3). An analysis was conducted on 45,182 SPL submissions in the Human Prescription, Human Over The Counter, Medical Device, and Animal label sets available as of April 22, 2013. The survey revealed elements that were primarily classes, those that were primarily attributes, and those that were unnecessarily verbose “wrapper” elements. Additionally, elements which are found in collections were identified using a “max and mean” algorithm.
SPL Documents have a fairly simple structure (Fig 2), combining a metadata-filled header and a body (contained in element <structuredBody>). The body contains a list of “section” elements. Section elements contain other section elements. While 90% of all files had 24 levels of nesting or less, some runaways include 40 levels. We note that every element deeper than 18 levels is related to a nested <containerPackagedProduct> element, which creates significant ambiguity for parsing drug products.
Each section is “typed” by the loinc_code attribute according to LOINC codes (e.g. “34067-9”) that identify the common sections of SPLs (e.g. “Indications and Usage”).
There are 87 codes allowed per ucm162057.htm
Maintaining the Drug Ontology: an Open-source, Structured Product Label API for the JVM
semantic clinical drugs, and semantic branded drugs
The database currently holds on ~106 entries; the authors are experienced with databases containing ~109 entries. In the short term, expansion of ingredients and dispositions will increase the database more quickly than new products. 2.5
Code generation (cogen) has been shown useful for creating
packages with numerous classes from OWL ontologies
We developed a custom code generation utility to generate Scala classes for the SPL XML Format using the referenced XML Schema Definition (XSD), which validates the SPL format, and the survey results (see section 2.2). Classes were identified as elements (and their wrappers) which contain a number of attributes and zero or more collections. Attributes and elements of collections may both be typed as other classes. Collections were implemented to hold lists of child node types when necessary. Node types that never contain other node types, such as <id />, <name>, and <code />, are created as typed attributes of the classes that represent the containing node types. Accessors were generated for attributes; iterators were generated for collections.
Instead of attempting to create classes at run-time through
the Java-beans paradigm
The SPL-API The parser and writer implementation is contained in the package dron.spl. Three sets of classes are included; classes that model the SPL XML format, classes that model the products and packages represented in the SPL XML files, and utilities necessary to manage Dailymed releases and updates (Fig 3 does not show utilities).
The root Scala class is “SPLDocument”. At least one SPLDocument instance is created for each SPL submission file parsed (see section 2.8). 2.6.1
SPLDocument exposes classes and methods that represent an abstract SPL document, which in turn utilize the cogen classes that model the XML more exactly (Fig 3). A recursive printing algorithm built into the cogen classes enables the SPL-API to write SPL files.
When an XML element is always wrapped by another element, and the parent element never contains another element, then only one cogen class is represented. There are fourteen wrapped classes in SPL-API.
As an example of the layered class design, consider the “ComponentStructuredBody” cogen class that represents the XML elements for the SPL document body. (This class is the “structuredBody” element wrapped with a “component” element.) With this class, you can create a collection of “ComponentSection” cogen classes. However, the better approach would normally be to use the “section methods” of SPLDocument (e.g. SPLDocument.addSection()) to manage the sections of a document. 2.6.2
Classes for Drug Products, Ingredients, and Drug Label Data were created, along with a base class for Drug Packages. Ingredients are maintained as a collection in the Products class since each product may contain multiple ingredients, and each ingredient has “active” or “inactive” status attribute. Additional attributes are planned, such as the “strength” of the Ingredient within the Drug Product.
The primary subject of an SPL file—a drug package—is implemented as two classes that are sub-classed from the base class Package; SimplePackage and ComplexPackage. Every instance of Package must be related to at least one instance of Product. SimplePackage relates to exactly one NDC, while a ComplexPackages contains a collection of SimplePackage(s) along with its own metadata.
Parsing one SPL file produces a list of Package instances, which will have one or more elements of Content of Labeling Data. Lists of Label Data are maintained as a collection in the appropriate Package instance. We provide utilities for downloading full release and periodic updates, unzipping downloaded archives, unzipping all archives in a given directory, and unzipping individual submission archives. Additional data lookup utilities will be added, for example to translate loinc_code(s) to text labels, which is hoped to also assist users in minimizing the future share of SPL UNCLASSIFIED sections.
For our use case, a key step in correctly identifying all of the
real drug products represented by the XML submission file
is to identify all NDCs, but NDCs are not encoded in the
XML scheme, and are only found in the free text of Product
Data Elements sections. They generally contain the text
string “NDC”, and they always conform to the NDC
10digit format (5-4-1, 4-4-2, or 5-3-2). We use pattern
matching to identify multiple NDCs per text section. The NDCs
that are found are checked against the National Drug Code
Directory
Of the 45,182 SPL submissions surveyed, 220 used the
XML tag-set “<relatedDocument>”. This tag includes the
“SetID” of a “Core Document Reference”
When using the Scala classes that represent the XML model (see section 2.6.1), each SPL section is contained within its proper document, and each related document is accessible by the SPLDocument.getRelatedDocument() property accessor.
When using the Scala classes that represent Drug Packages (see section 2.6.2), all related documents are “flattened”, and each section is included from all documents. Inheritance rules are unclear, so all sections are currently collected by section type. All identified Drug Products and Drug Packages will be included in the list.
In addition to the SPL-API, a “helper” will be developed to load the parsed SPL data into the DrOn relational schema (represented as gears in Fig 1). A plugin system added to the DrOn builder will be able to identify the proper resourcespecific plugin and pass the initialization necessary to complete loading for the next update.
We have developed an open-source API for processing SPLs in a Java Virtual Machine. A developer’s release will be made available at the start of VDOS 2013, and will be available at: https://bitbucket.org/rogerhall68/spl-api.
Ongoing work includes loading processed data into the Drug Ontology to keep it current as new drug products are released.
This work was supported by award number UL1TR000039 from the National Center for Advancing Translational Sciences, award R01GM101151 from the National Institute for General Medical Science, and the Arkansas Biosciences Institute, the major research component of the Arkansas Tobacco Settlement Proceeds Act of 2000. This paper does not represent the views of NCATS, NIGMS, or NIH.