Semantic interoperability is essential when carrying out postgenomic clinical trials where several institutions collaborate, since researchers and developers need to have an integrated view and access to heterogeneous data sources. In this paper we present a solution that uses an ontology based on the HL7 v3 Reference Information Model and a set of R2RML mappings that relate this ontology to an underlying relational database implementation, and where morph-RDB is used to expose a virtual SPARQL endpoint over the data. In previous e orts with other existing RDB2RDF systems we had not been able to work with live databases. Now we can issue SPARQL queries to the underlying relational data with acceptable performance, in general.
In the last years, clinical trials have started introducing genomic variables [
In previous works [
sources where medical ontologies are also being used, and has already been used
for providing some form of interoperability among real data sources [
RDB2RDF mappings are used to expose data from relational databases as RDF datasets. Two major types of data access mechanisms are normally provided by RDB2RDF tools: i) data translation (a speci c case of ETL - Extract, Transform, Load -), where data are materialized into RDF datasets and stored in a triple store (e.g., Virtuoso), which provides a SPARQL endpoint; and ii) query translation, where SPARQL queries are directly translated into SQL according to the speci ed RDB2RDF mappings, and evaluated against the relational database, and where results are translated back using the mappings to conform with the SPARQL query. In our case, we are interested in using RDB2RDF mappings to make the data stored in our SQL implementation available according to an ontology that re ects the HL7 version 3 RIM. Furthermore, we have a strong requirement to use a query translation approach, given the importance of having fresh results, what cannot be always ensured in the data translation approach.
Our rst attempt [
Later, we started using morph-RDB [
This paper is organized as follows. Section 2 discusses the necessary background such as our current model for storing medical data, the HL7 RIM ontology, the R2RML mapping language, and our query translation engine morphRDB. We discuss some optimization techniques in Section 3. In Section 4 we discuss the set of queries that we use for the evaluation. Finally in Section 5 we provide some conclusions and describe some of our future work in this area, including our deployment plans in aforementioned healthcare institutions.
In this section we will review the main foundations of the work that we present in the paper, namely HL7 and the HL7 RIM, the R2RML language, and morphRDB. 2.1
HL7 RIM
Recent years have witnessed a huge increase of biomedical databases [
Among the many Detailed Clinical Models that have been reviewed for the
integration of biomedical datasets [
The HL7 RIM backbone contains three main classes (Act, Role and Entity), which are linked together using three association classes (Act-Relationship, Participation and RoleLink). The core of the HL7 RIM is the Act class. An Act is de ned as \a record of an event that has happened or may happen". Any healthcare situation and all information concerning it should be describable using the RIM by including the type of act (what happens), the actor who performs the deed and the objects or subjects Entity that the act a ects to Role. Some additional information may be provided to indicate location (where), time (when), manner (how), together with reasons (why) or motives (what for). Act and Entity classes have some specializations that add some attributes, such as Observation (a subclass of Act), or Person (a subclass of Entity).
This standard is able to represent all kinds of healthcare situations and any kind of information associated with it. Based on this idea, we have de ned a subset of the HL7 RIM schema, where we implement the classes and attributes that are necessary to represent the scenario for sharing clinical data of breast cancer clinical trials: { Act, with the subclasses Observation, Procedure, SubstanceAdministration, and Exposure. { Role. { Entity, with the sub-classes LivingSubject, Person, and Device. { The classes; i)ActProcedureApproachSiteCode, ii) ActMethodCode, iii) ActTargetSiteCode, iv) ActObservationInterpretationCode, and v)
Besides, attribute data types are rather complex on the RIM, so they are changed according to the mentioned scenario, following HL7 recommendations. Therefore some attributes were simpli ed in the relational model compared to those de ned by HL7 v3 standard. To improve a better performance and knowledge on the HL7 RIM schema, it is de ned a set of views. These views cover the access retrieval requirements for the clinical scenario. Therefore it is implemented a di erent view for obtaining patient data due to its provenance (Observation,
Therefore, the de ned HL7 RIM based CDM above ful lls the requirements needed by breast cancer in clinical trials scenario. Furthermore, we have created an ontology that re ects the HL7RIM model6, available for others to reuse. 2.2
R2RML
R2RML [
morph-RDB
morph-RDB, which belongs to the morph suite7, i.e., receives as an input the
connection details to a relational database, an R2RML mapping document and
a SPARQL query and translates the query into SQL according to the R2RML
mapping, evaluates it into the underlying relational database and translates
back those results into the format required as a result of the SPARQL query
evaluation. The query translator component in morph-RDB implements the
algorithm described in [
the query translation using the notion semantic-preserving, in other words, the results of the SPARQL and SQL return the same answers. We extend their work by relating those mappings and functions with the R2RML mapping elements. Example 1. Consider the following table v person(patientId, patientName, gender, actId) that stores the information about patients. This table is mapped to class Patient with the attribute patientId as the identi er (together with base URI for class Patient) of the instances. Attributes patientId and patientName are mapped to ontology properties hasID and hasName, respectively. Now let's add another table v observation(actId, title, code) that describes observations. This table is mapped to class Observation with actId as the identier of the instances, and the attribute title is mapped to property hasTitle. patientId and actId are primary keys of the tables v person and v observation, respectively. Furthermore, the actId of table v person is a foreign key that refers to the column actId of table v observation, and this relation is mapped to property hasObservation.
The instances of the tables can be seen in Figure 1.
FROM T1 INNER JOIN T2 ON T1.patientId = T2.patientId; where T1 = (SELECT patientId FROM v person WHERE patientId IS NOT NULL) and T2 = (SELECT patientId, patientName FROM v person WHERE patientId
the rst and second triple patterns, respectively. 3
The query translation technique presented above do not necessarily generate optimal SQL queries. Based on the set of SPARQL queries we have evaluated, we have observed that several patterns occur frequently. Hence we describe optimization techniques that can be applied in order to generate more e cient queries. { Self-join elimination. A set of triple patterns connected by the AND operator and sharing the same subject occur frequently. We call this pattern Subject Triple Group (STG). Using a nave query translation, each triple pattern corresponds to an INNER join in the generated SQL query. We have extended our query translation technique so that in addition to handling triple patterns, each of the mappings/functions is also able to handle STG. Example 2. Consider again the SPARQL query in Example 1. With self-join elimination, now the result of translating that query is:
{ Left-outer join to inner join. Another pattern is a Subject Triple Group with Optional (OSTG), that is an OPTIONAL pattern that consists only one triple pattern, preceded by an STG pattern or a triple pattern. Because the OPTIONAL keyword corresponds to a left outer join, naively translating this pattern produces one left-outer join for each OPTIONAL pattern. We extend our query translation technique, so that the optimized query translation generates an inner join, cheaper to evaluate than left-outer join, by removing the conditional expression IS NOT NULL corresponding to the function genCondSQL of the triple pattern in the OPTIONAL pattern.
Example 3. Consider the following pattern: { ?p :hasID :pid . OPTIONAL { ?p :hasName ?pname . } } Without left-outer join elimination, the result of translating this query is:
(SELECT patientId FROM v_person
(SELECT patientId, patientName FROM v_person
By changing the type of join from left-outer to inner, and removing the conditional expression name IS NOT NULL, and applying the self-join elimination (O1), the optimized query generated becomes:
{ Phantom triple pattern introduction.
Example 4. Consider the following pattern, which is neither an STG pattern nor an OSTG, thus, none of the aforementioned optimizations can be applied. { ?p :hasObservation ?o .OPTIONAL { ?s :hasTitle ?t . } } In order to exploit those optimisations we have presented so far, this query has to be transformed into another query whose resulting query translation can be optimised. To do that, we use the fact that for every IRI x, the fact (x a rdf:Resource) holds, so that we can safely add this triple pattern to the query without changing its semantics. We call such triple pattern a phantom triple pattern. The result of adding the phantom triple pattern is: Now with the new pattern that emerged, the optimization for OSTG pattern can be applied. 4
We have collected a total of 45 SPARQL queries that are used in the patient recruitment and cohort selection scenario for breast cancer clinical trials. The complete list of queries and their natural language descriptions are available at http://bit.ly/1LecA7L. From this query list, we asked our domain experts to group the queries into a set of ve groups that are representative of the whole set, and they are shown in Table 1.
Representative Similar queries query Q01 Q10 Q14 Q34 Q45 { Observation query (Q45). This query retrieves the information of patients who have been detected a category T2 breast tumor. It consists of 14 triple patterns and 5 unique subjects. There are 4 OPTIONAL patterns, one of them nested, and 2 FILTER patterns.
The machine used in our evaluation has the following speci cations: CPU Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 8 GB of RAM, 750 GB HDD with Ubuntu Server 12.04 and MySQL Server 5.5. The dataset contains information of 3 months of historical clinical data, with 4674 patients and 65056 acts, among many other tables. The total size of the database is 105 MB. This database will be growing in the future, as more data is added as a result of the data integration processes carried out in the context of the projects where the database is being generated.
We were interested in comparing morph-RDB with another well-established RDB2RDF engine, such as D2R, considering the total time required for the execution of the SPARQL queries. That is, we include in our calculation the time required to initialize the engine, the time needed for SPARQL-to-SQL query translation, the time needed to evaluate the SQL queries, and the time needed to translate back the result from the database using the mappings into the result expected by the SPARQL queries. Figure 2 provides details for the ve selected queries, which are also similar to the results obtained for the other queries in our query set. We can easily see that in most cases our total execution time is much lower than the one required for D2R Server. In some cases (queries Q14 and Q45) D2R Server was not able to produce results in less than ve minutes. The results for the rest of the queries are available at http://bit.ly/1LecA7L.
We were also interested in how the SQL queries that result from the query rewriting approach perform in comparison to the SQL queries that would have been natively created by a SQL expert. For this reason, we asked a domain expert with good knowledge of the HL7 RIM relational database to construct SQL queries that were semantically equivalent to the corresponding SPARQL queries. In other words, without taking into account the mapping elements, such as template or URI generation, the SPARQL and SQL queries should return the same answer.
We evaluated each query 5 times in cold and warm modes. In the cold mode, we restart the server and empty the cache before we evaluate the next query. In the warm mode, we skip these steps and execute the queries directly one after the another. We measure the averages of query execution time and normalize the query evaluation time to the native query evaluation time. As an additional note, we can only do this type of evaluation using morph-RDB and native queries, as D2R Server produces multiple SQL queries in many cases and performs joins in memory, what makes it not comparable with the native or morph-RDB queries.
The results from both evaluation modes show a similar trend. Furthermore, we observed that in the warm mode, the database server doesn't lose its capability of reusing previous results of the query cache. This is re ected by the fact that only the rst run of the query takes more time to complete, while subsequent queries can be evaluated with only a fraction of that time. Some of those queries produced by morph-RDB can be evaluated in a reasonable time. For example, the resulting query translation of query Q01 can be evaluated in a similar time as the native query Q01. Furthermore, the resulting query translation Q34 can be evaluated in less time than its corresponding native queries, which can be an indicator that there might be still room for improving the corresponding native query. Some other queries, such as Q10 and Q45, need more time to be evaluated, being in the range of 20-35x slower than the corresponding native queries, in which we still consider them as acceptable.The query Q14, however, needs more investigation, as it takes a lot of time to be evaluated, 380-500x slower in terms of normalized time to native queries. We suspect this is caused by the arithmetic operation that is performed over the resulting translation queries. 5
In this paper we have shown that SPARQL queries can be used as a means to query relational clinical data that is integrated into an HL7 version 3 RIM database implementation. We collected a set of 45 real SPARQL queries required by our application domain and that will be deployed in a set of medical institutes, chose ve of them as the most representatives ones, and evaluated those queries using D2R Server and morph-RDB as our RDB2RDF tools. We have shown that, in general, we got a better result with morph-RDB than D2R Server, what allows now using this approach for accessing relational data using SPARQL.
However, there are still some important remaining challenges to be considered. We still have queries that require too much time to be evaluated, (e.g. query Q14), because of the arithmetic operation that is included in the SPARQL query and in its resulting translation into SQL. Investigating and designing optimizations for dealing with this type of query will be part of our future work.
This work has been funded by Ministerio de Econom a y Competitividad (Spain) under the project "4V: Volumen, Velocidad, Variedad y Validez en la Gestion Innovadora de Datos" (TIN2013-46238-C4-2-R), by the European Commission through the EURECA (FP7-ICT-2011-7-288048) project and also by the Ministry of Health of the Spanish Government under Grant PI13/02020.