Renewed global e orts to deploy Automatic Identi cation and Data Capture (AIDC) technologies, such as barcodes, on vaccine packaging in developing countries are currently underway. An opportunity to evaluate Linked Data technologies for generating an ecosystem of data connectedness and interoperability in the vaccine supply chain presents itself. We discuss the VacSeen project, a Linked Data-based information system to track vaccines through visualization and authentication of barcode scans on vaccine packaging using mobile phones. The project is aimed at enabling endeavors such as logistical planning and integration with health information systems, demand forecasting, anti- counterfeiting and diversion measures, and post-marketing surveillance by pharmaceutical companies, supply chain contractors, and public health agencies. By forming an abstraction layer over siloed data while necessitating minimal modi cation of existing architecture, VacSeen can help minimize the technical, operational, and political friction often associated with fostering data interoperability. We discuss VacSeen's software architecture and present sample data analytics that highlight VacSeen's ability to facilitate the interoperability of diverse and non-standardized data sources. Limitations of the current framework and areas of future exploration and expansion are also discussed.
Vaccines have been globally recognized as a critical public health intervention [
Several countries have issued directives to vaccine manufacturers to include
barcodes on vaccine packaging 2,3 [
Numerous commercial entities are presently engaged in developing
technologybased solutions for tracking vaccines in developing countries 4,5,6. Despite
improved information ow, issues about interoperability and at-scale last mile
tracking continue to persist. Several studies have reported the e ectiveness of
using barcodes in tracking vaccine consumption [
We demonstrate the utility of VacSeen in authenticating barcode scans and generating attendant rich contextual information. We geolocate and classify the scans based on whether or not they were recorded by authorized personnel using authenticated devices. We learned from vaccine manufacturers that such granular visibility into vaccine movement in developing countries does not presently exist. In this publication, we mimic data from multiple sources|a eld-based mobile application, a supply chain database with information about barcodes, and a healthcare provider database with details about personnel and devices 2 http://www.sidley.com/news/major-vaccine-standards-change-in-china-01-24-2011 3 http://www.securingindustry.com/turkey-sets-short-timeframe-for-pedigree-system/ s15/a29/ 4 http://vaxtrac.com/ 5 http://www.logistimo.com/products 6 http://www.path.org/vaccineresources/supply-chain-and-logistics-systems. php scanning the barcodes|to demonstrate that Linked Data technologies can be e ectively used to render data from multiple sources interoperable. In addition, we leverage the Linked Open Data (LOD) cloud to enrich the dataset by generating biomedical factsheets about the vaccines as well as identifying nearest airport to a selected scan location. Such applications demonstrate the utility of Linked Data in activities such as knowledge management, logistical planning, and product recall.
Section 2 presents an overview of the VacSeen system architecture and presents each software component in detail. Section 3 presents proof-of-concept results obtained from VacSeen such as aggregate statistics of vaccine consumption and geo locations of healthcare workers handling vaccine packaging. Finally, Section 4 summarizes the key ndings of our study and scope for future work. 2
The presence of barcodes on primary and secondary packaging presents the opportunity of using an EPCIS v1.17(Electronic Product Code Information Services) event as a proxy for a vaccine transaction event. EPCIS is a standardized event oriented speci cations prescribed by GS1, a standards organization,8 for enabling traceability. Here a transaction event can either be traversal through the supply chain or the administration of the vaccine. By including barcode scanning as a required step in standard operating procedure, a record of every vaccine receipt event can be stored.
tiple relational databases, an ontology for mapping the conversion of relational data into Linked Data, a triple store for storing the converted Linked Data, and a web-based visualization platform (Fig 1). 2.1
Our focus while developing the Android application was testing a Minimum Viable Product in the eld that we can add features to at subsequent stages of development. As a result, the role of the VacSeen application was con ned to that of a generator for scan data.
The worker is expected to scan the barcode on vaccine's package as an identier of a transaction event. We integrated the widely used Zxing barcode library9 into the application to facilitate barcode scanning. The app collects the following information that serve as components of the business rules for scan authentication: { Content and format of the barcode scanned. { Worker's phone number that serves as operator ID. { The device's International Mobile Equipment Identity (IMEI) number that serves as device ID. { Spatial and temporal data.
Despite the availability of several other device identi ers, we chose the IMEI number because of its relative ubiquity and uniformity. The capture of IMEI number can give rise to concern among users as the application requests access to call records during installation. However, we assume that the users of the application are authorized personnel using government- or employer- issued devices as is often the case with immunization projects. As a result, we circumvent concerns about privacy breach that would otherwise typically arise. 2.2
For storing and hosting the data, we used WAMP Server (Apache, PHP, MySQL on Windows)10. The data from VacSeen mobile application was stored in a MySQL database hosted on an Apache server with PHP as the server side scripting language. A JSON parser in the mobile application was used for transmitting the data which was then written into the database by a PHP script. We chose WAMP Server to mimic the use of MySQL on Windows computers in the barcode project in Tanzania.
In addition to the database for storing inputs from the mobile application, we created another database of authorized operators (scanning personnel) and devices (mobile phones) to mimic those used by the healthcare authorities.
With numerous options available for Relational Database (RDB)-to-Resource
Description Framework (RDF) translation [
We used the D2RQ mapping tool and the dump generator for the project. To customize the mapping produced by the generate-mapping script, we used resources from multiple well-known vocabularies such as dbpedia-owl, foaf, and eem in addition to a self-created one named VacSeen1 12. The mapping les are publicly available13.
We enforced integrity constraints on the data during translation by specifying datatypes in the mapping les. Additionally, we applied lters in the SPARQL queries to disregard records with incorrectly captured data elds. 2.4
For creating the VacSeen1 ontology, we reused sections of the EPCIS Event Model ontology (EEM)14 and the Vaccine Ontology (VO)15. The incorporation of concepts from the two ontologies enabled us to seamlessly bridge logistical and biological information for our future applications. We generated persistent uniform resource identi ers (URIs) for the ontology elements and are currently working on making them de-referenceable. We used a light-weight ontology with just enough formalization to enable detailed querying. As the datasets attain greater complexity, it will be necessary to incorporate a higher degree of semantics within the ontology. However, we will position most of the complexity in our queries instead of the ontology in order to control for reasoning errors.
EEM is an OWL 2 DL ontology for modelling EPCIS events. EEM
conceptualises various primitives of an EPCIS event that need to be asserted for the
purposes of traceability in supply chains. Development of EEM was informed
by a thorough review of the EPCIS speci cation and extensive discussions with
trading partners implementing the speci cation. The modelling decisions [
The EEM ontology structure and its alignment with various external
ontologies is illustrated in Figure 2. The ontology is composed of modules that de ne
various perspectives on EPCIS. The Temporal module captures timing
properties associated with an EPCIS event. It is aligned with temporal properties
in DOLCE+DnS Ultralite (DUL)17. Entities de ning the EPC, aggregation of
EPCs and quantity lists for transformation events are part of the Product
module. The GoodRelations18 ontology is exploited here for capturing concepts such
as an Individual Product or a lot (collection) of items, SomeItems of a single
type. Information about the business context associated with an EPCIS event
is encoded using the entities and relationships de ned in the Business module.
RFID readers and sensors are de ned in the Sensor module. The de nitions here
are aligned with the SSN19 ontology. The EPCISException module incorporates
the hierarchy of the most commonly observed exceptions [
Since EEM o ers an extensive model for EPCIS events, mapping the elements of the relational databases to classes and properties of the ontology was our default approach. However, we created additional properties and classes as needed. For instance, the location coordinates from the VacSeen application are stored in the scan event table of the vacseen connect database as scanLat and scanLong columns. To map the latitude and longitude coordinates, we created the vacseen1:latitudeOfBarcodeScanEvent and vacseen1:longitudeOfBarcodeScanEvent 17 http://ontologydesignpatterns.org/ont/dul/DUL.owl 18 http://purl.org/goodrelations/v1 19 http://purl.oclc.org/NET/ssnx/ssn properties in the VacSeen1 ontology. Other customized properties include scanID and operatorID.
The scanID is a 20-digit composite unqiue identi er of a scan event generated from scan attributes to facilitate an intuitive understanding about it. The information encoded in the ID can be useful in implementing access controls, protecting personnel privacy, limiting data exchange volumes, and partially o seting the ambiguity arising from multiple scans of unserialized GTINs. 2.5
We chose GraphDB-Lite20 semantic repository implemented on Sesame for our project as it o ers owl based reasoning and is free, stable, scalable, and easy to use because of an intuitive administrative interface that comes with the distribution. We used Apache Tomcat 8.0 servelet container as per the recommended installation settings on a personal computer.
We loaded data from the 3 databases |vaccine data, healthcare system data, and barcode scan data|(c.f Fig 1) into a single triple store. Additionally, we selectively incorporated relevant data for our analyses from the LOD cloud to circumvent the issue of sporadic unavailability of public SPARQL endpoints. By having the data in a single store, we excluded the need for more complex federated SPARQL queries that tend to be resource and time intensive. As the volume of data scales, the triple store data storage and access architecture will, of course, require re-design but we do not explore that in this paper. 2.6
The web interface of the project is publicly available21 and was built using the Bootstrap framework. The interface presently enables querying a static dataset of EPCIS events to display 3 levels of scan authentication using Google Maps, attendant analyses, and Linked Data applications.
The marker data is generated by querying the Sesame triple store using the SPARQL query language over jQuery. In the absence of automated formatting of SPARQL queries in JavaScript, we formatted the queries through string concatenation. 3
In this section we provide contextual information about vaccine scans, aggregate statistics, and description of two LOD-based applications. For the purposes of this study, we make use of simulated data where 22 researchers and volunteers in United States and India were asked to scan barcode labels (vaccines or otherwise) randomly over a period of 28 days.
The users generated 217 scan events for analysis of which 20 events from 3 users did not capture the location coordinates of the scan and returned values of 20 http://ontotext.com/products/ontotext-graphdb/graphdb-lite/ 21 http://parthasb.scripts.mit.edu/ (a) SPARQL Output - Intermediate Validation Query
(c) MySQL output - Eligible scans for In(b) SPARQL Output - Advanced Valida- termediate Validation tion Query '0.0' for latitude and longitude. This is possibly a result of the lag experienced by devices at times to report their location coordinates. Subsequent versions of the mobile application will look to eliminate this problem by appropriate data bu ering techniques. 3.1
Several entities such as shipping agencies, inventory stock controllers, and healthcare workers, are engaged in vaccine logistics; all of whom can use VacSeen to scan barcodes during operations. It is therefore important to provide additional context for each barcode scan so as to get a deeper understanding about vaccine handling operations in the eld.
To illustrate this, we randomly designated two authorized operators (IDs ending in '3932' and '2951') and an authorized device(ID ending in '1014' belonging to the rst of the aforementioned operators. A scan by operator '3932' using device '1014', for example, can be used to indicate a vaccine administration scan by a healthcare worker while a scan by '2951' might indicate an inventory status scan by a non-healthcare worker.
Following are some authentication visibility statistics tested in the study: { All Scans: Displays all of the 197 barcode scans (vaccine label or otherwise) by any operator and device using the VacSeen software. { Basic Validation: Of the 197 scans, identi es the 37 scans that entailed scanning of a vaccine GTIN present in the supply chain database. { Intermediate Validation: Distinguishes the 3 scans that were undertaken by the two authorized operators on vaccine GTINs (Fig 3a) as can be veri ed from the MySQL database (Fig 3c). { Advanced Validation: Adds to the Intermediate Validation by distinguishing the 2 scans that were done using the sole authorized device. As the list of authorized devices only has one device registered to operator '3932', one of the scans registered in Intermediate Validation does not qualify as an Advanced Validation (Fig 3b). The di erences among the validation levels are illustrated in Fig 4. 3.2
In addition to barcode scan validation, we undertook preliminary analyses of the data to assess operator performance by measuring scans by devices and visualizing overall temporal trends in scans. Visualization of aggregate statistics was useful in determining individual and collective user activity which can be considered representative of analysis of personnel e ciency during enterprise applications. 3.3
To demonstrate the bene t of linkage to the LOD cloud, we generate
biomedical factsheets about the vaccines comprising information such as type, route
of administration, and Medline and Anatomical Therapeutic Chemical (ATC)
numbers from DBpedia [
In this paper, we report the development of VacSeen, a Linked Data-based information architecture for authenticating barcode scans on vaccine packages using mobile phones. We demonstrate how the software framework can be used to enable vaccine scan authentication visibility in vaccine transportation and administration logistics. For the purposes of this study, we make use of simulated data but the evolution of the project will be anchored to a pilot study.
We will extend the mobile application to facilitate two-way communication so that the user can receive information compliant with access control mechanisms. Additionally, we will explore the possibility of capturing the data from the mobile device to a triple store directly.
With respect to data storage and querying, we will migrate to a cloud-based solution with due consideration to scale and security. We will continue to build applications leveraging the LOD cloud, such as generating comprehensive individual factsheet for every scan. Such a factsheet will draw from both native and external datasets. To manifest such applications, we are currently engaged in RDFlizing open datasets of interest. Other workstreams under consideration are using inferencing to classify data from external sources, and extending the VacSeen1 ontology to answer more complex questions in a broader set of use cases. Going forward, we will extend VacSeen in a bid to create an ecosystem of Linked Data with low adoption barriers to help address complex issues associated with transportation of healthcare goods and services to resource-constrained settings.