This is an open-access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Research Protocols, is properly cited. The complete bibliographic information, a link to the original publication on http://medinform.jmir.org/, as well as this copyright and license information must be included.
Because of the increased adoption rate of electronic medical record (EMR) systems, more health care records have been increasingly accumulating in clinical data repositories. Therefore, querying the data stored in these repositories is crucial for retrieving the knowledge from such large volumes of clinical data.
The aim of this study is to develop a Web-based approach for enriching the capabilities of the data-querying system along the three following considerations: (1) the interface design used for query formulation, (2) the representation of query results, and (3) the models used for formulating query criteria.
The Guideline Interchange Format version 3.5 (GLIF3.5), an ontology-driven clinical guideline representation language, was used for formulating the query tasks based on the GLIF3.5 flowchart in the Protégé environment. The flowchart-based data-querying model (FBDQM) query execution engine was developed and implemented for executing queries and presenting the results through a visual and graphical interface. To examine a broad variety of patient data, the clinical data generator was implemented to automatically generate the clinical data in the repository, and the generated data, thereby, were employed to evaluate the system. The accuracy and time performance of the system for three medical query tasks relevant to liver cancer were evaluated based on the clinical data generator in the experiments with varying numbers of patients.
In this study, a prototype system was developed to test the feasibility of applying a methodology for building a query execution engine using FBDQMs by formulating query tasks using the existing GLIF. The FBDQM-based query execution engine was used to successfully retrieve the clinical data based on the query tasks formatted using the GLIF3.5 in the experiments with varying numbers of patients. The accuracy of the three queries (ie, “degree of liver damage,” “degree of liver damage when applying a mutually exclusive setting,” and “treatments for liver cancer”) was 100% for all four experiments (10 patients, 100 patients, 1000 patients, and 10,000 patients). Among the three measured query phases, (1) structured query language operations, (2) criteria verification, and (3) other, the first two had the longest execution time.
The ontology-driven FBDQM-based approach enriched the capabilities of the data-querying system. The adoption of the GLIF3.5 increased the potential for interoperability, shareability, and reusability of the query tasks.
A substantial number of health care records are routinely accumulated in clinical data repositories because of the increasing use of electronic medical record (EMR) systems. Previous studies have shown that these large volumes of clinical data offer great potential for discovering new knowledge and improving the quality of health care [
Experts from various domains can apply a query approach to elucidate the distributions of complex data by formulating and executing queries used for identifying the desired data that are stored in large clinical data repositories. Previous studies have proposed several query approaches based on specific query tasks that assist domain experts in retrieving clinical data for further analyses [
Extant literature on data querying from clinical data repositories are based on the following three considerations: (1) the interface design used for query formulation, (2) the representation of query results, and (3) the models used for formulating query criteria.
Regarding the design of a user interface for formulating queries, users can formulate queries by employing low-level query languages, such as Structured Query Language (SQL), or by using query-building tools that allow them to create query tasks easily using the features available with these tools.
The application of low-level query languages, such as SQL, presents several potential difficulties. First, experience in database querying is required. The users who employ SQL commands to query a database directly must possess a detailed understanding of the information in that database, including the table definitions, the table column types, and the relationships among the tables. Second, the SQL command syntax for complex queries could be difficult to write. When data querying involves a query algorithm, the SQL command syntax is complex, which can make it difficult to analyze the query results of these intermediate processes.
To minimize the complexity of formulating queries by using SQL commands, researchers have proposed and developed specific query-building tools to assist users in building and executing database queries. For example, RetroGuide was proposed to assist users who had limited database experience in formulating database queries [
Regarding the representation of query results, various formats can be employed to present the queried data, including free text, structured tables, and visual charts. Rich data representation methodologies can assist in improving the users’ understanding of the database query results.
RetroGuide provides a table-based three-level hierarchical report of query results, including a summary report, detailed report, and information view of each patient [
Regarding the models used for formulating the database query criteria, the adoption of interoperable formulation information models has improved the opportunity for users to consistently query various clinical data repositories. Moreover, information models that allow powerful expression for query criteria formulation can enhance the capabilities of database queries.
Austin et al developed an information model for designing generic interfaces for EMR systems [
Ontology-based approaches have been widely employed in various medical domains [
In this study, we developed a Web-based approach for enriching the data query based on the three considerations discussed above. A prototype system was developed to test feasibility of applying a methodology for building a query execution engine using flowchart-based data-querying models (FBDQMs) by formulating query tasks using the existing Guideline Interchange Format (GLIF). The FBDQM was introduced, developed, and implemented in formulating query tasks by employing the flowchart and objects defined in the GLIF3.5 [
The overview of the methodology used in the data-querying tool based on ontology-driven methodology and flowchart-based model.
Clinical guideline representation languages were developed for formulating paper-based clinical guidelines in a computer-interpretable format. Currently, several medical-related institutions are developing numerous clinical practice guideline representation languages and models, including Asbru, EON, GLIF, GUIDE, PRODIGY, and PROforma [
To formulate the query tasks using GLIF3.5, the concepts and criteria of the text-based query tasks should be categorized as the corresponding classes of the GLIF3.5 ontology. The
To formulate the query tasks, users must employ Protégé, a knowledge-based editing software that provides a graphical user interface for the formulation of query tasks based on the GLIF3.5 flowchart. The query tasks are formulated by building the flowchart and specifying the criteria and data items in each node of the flowchart through the Protégé environment (see
The entire query task can be separated into numerous subtasks, and each subtask can be represented using a node in the flowchart. The following five predefined GLIF3.5 classes were used: (1) action, (2) decision, (3) branch, (4) synchronization, and (5) patient state. The detailed components of each node were further specified through Protégé based on the predefined GLIF3.5 ontology.
After using the GLIF3.5 ontology to formulate the query tasks, the nodes were exported from Protégé in the XML format and subsequently imported into the query execution engine for data query and retrieval of the clinical data repository (see
A Web-based data-querying tool was implemented and the clinical data were queried using the FBDQM-based query execution engine. The architecture of the query execution engine comprises eight major components (
The set of logical processing components includes the GLIF3.5 ontology interpreter, flowchart-based model builder, query language generator, clinical data retriever, and mapping component. The set of visual representation components contains the GLIF3.5 ontology information viewer, query criteria selection interface, and clinical data representation interface.
The architecture of the FBDQM (flowchart-based data-querying model)-based query execution engine.
A query task is formulated using the predefined GLIF classes. A GLIF3.5 ontology interpreter is necessary for parsing the GLIF-based query tasks and translating them into data query components for data retrieval. For example, following the interpretation process, a flowchart-based model builder was employed to create a flowchart-based model. A flowchart was displayed in the query criteria selection interface to provide an overview of the query task, and additional relevant information (eg, the criteria and data items in each node of the flowchart) could be viewed in the GLIF3.5 ontology information viewer.
The formulated query tasks were exported as XML-formatted documents and subsequently imported into the GLIF3.5 ontology interpreter in the query execution engine. The GLIF3.5 ontology interpreter was employed to interpret the query criteria and data items in the following five classes: (1) action, (2) decision, (3) branch, (4) synchronization, and (5) patient state. The original meanings of these classes in GLIF3.5 and their usages in this study are detailed as follows [
The flowchart-based model builder generates the flowchart-based model based on the interpreted results from the GLIF3.5 ontology interpreter. An interpreted query task is used to generate a corresponding FBDQM. The generated FBDQM contains the information relevant to the formulated query tasks, including the structure of the flowchart describing the overall query task and the detailed information of each query subtask, such as the query criteria and the related data items in each node (
A graphical flowchart of the FBDQM is used to present the workflow of a query task through the query criteria selection interface. Logical query criteria and relevant FBDQM data items are the inputs used by the query language generator to generate the corresponding query languages.
The flowchart-based data-querying model (FBDQM) containing the structure of query task workflow and the information of each node in the query task.
The query criteria selection interface in
The left side of
Furthermore, the query criteria selection interface provides the functionality of a mutually exclusive setting. For example, the degree decision node shown in
The query criteria selection interface and the GLIF3.5 ontology information viewer.
The flexibility in selecting all or partial nodes of the flowchart for participating in the execution of query operation.
The query criteria of the selected nodes can be displayed in the query criteria selection interface.
Various interfaces were designed to provide multiple layers of views for the query tasks. An overview of the query tasks can be displayed in a flowchart in the query criteria selection interface. When a query task is highly complex, an overview of this query task can be viewed in a simplified flowchart. Each node of the flowchart contains a set of query criteria, and the detailed information (eg, the data items included in query criteria) can be viewed in the GLIF3.5 ontology information viewer by selecting the flowchart node.
The specific standards for medical terminologies and information models, such as vMR [
For example, as shown in
To map the data items in a GLIF-formatted query task and those in a local clinical data repository, two mapping concepts proposed in the knowledge-data ontological mapper (KDOM) were employed [
The query criteria in the selected nodes from the FBDQM were transferred to the query language generator to generate the query language.
During the query language-generation process, the data items included in the query criteria of the selected nodes could be mapped onto the corresponding data items in the clinical data repository. In the query language generator, predefined mapping information is applied to map the data items. Mapping involves both the direct and indirect mapping. In direct mapping, the data items are mapped directly to the values of a specific column of a database table (eg, “select Personal_ID from Diagnosis where ICD9_Code=‘155.0’”; the data item was mapped directly to the value of the “ICD9_Code” column). In indirect mapping, the data items are mapped indirectly though multiple column values of a database table (eg, “select Personal_ID from Laboratory where Result_String=‘Controllable’ and Item_Name=‘Ascites’”; the data item was mapped indirectly though multiple column values, ie, the “Result_String” column and the “Item_Name” column).
After the data item mapping process is complete, the query language generator creates the corresponding SQL-based data query. The query language generator reads the query criterion in GLIF3.5 format and translates it into one or several simplified SQL criteria. Some examples of the query criteria in GLIF3.5 and the corresponding translated SQL queries are presented in
To implement specific advanced queries to retrieve data from the repository, both SQL and high-level languages (ie, C#) were employed. For example, to implement the problem of “at least 2 of (Subcriterion 1, Subcriterion 2, Subcriterion 3, Subcriterion 4, and Subcriterion 5)” shown in
The GLIF3.5 ontology information viewer. The selected node, “degree decision,” and its corresponding information in GLIF3.5 format.
The examples of the query criteria in GLIF3.5 and the corresponding translated SQL queries.
Query criteria format | Query criteria |
GLIF3.5 | 1. ICD9=155.0 |
Translated SQL queries | 1. select Personal_ID from Diagnosis where ICD9_Code=“155.0” |
GLIF3.5 | 2. at least 2 of (Ascites==“Controllable,” ICG is within 15 to 40, Prothrombin_Activity is within 50 to 80, Serum_Albumin is within 3.0 to 3.5, Serum_Bilirubin is within 2.0 to 3.0) |
Translated SQL queries | 2.1. select Personal_ID from Laboratory where Result_String=“Controllable” and Item_Name=“Ascites” |
The clinical data retriever executes the query operation based on the query criteria in the selected nodes from the FBDQM. The query execution process commences from the nodes in the top layer of the flowchart and proceeds to those in the bottom layers. During query operation process in each node, the patients’ data are retrieved based on the translated SQL criteria, and the patients are reserved when they meet the query criteria specified in the node. The four types of notations that are used to represent the workflow and operations of the query execution in the FBDQM-based query execution engine are as follows: (1) QC(node), (2) PL(node), (3) PLS(node), and (4) PN(node).
QC(node) represents the query criteria included in the node. PL(node) constitutes the patient list, which contains the patients satisfying the query criteria included in the node. PLS(node) represents the size of the patient list, PL(node), indicating the number of patients who satisfy the query criteria included in the node. Finally, PN(node) is the list of the parent nodes of the node.
The left side of
The query results retrieved by using the FBDQM-based query execution engine in
Following the query execution of one node, the number of patients retrieved by the query operation is displayed dynamically beside the node in the flowchart. For example, in
The clinical data representation interface.
The clinical data representation interface showing the retrieved results of “degree of liver damage when applying a mutually exclusive setting” query task.
The clinical data representation interface showing the retrieved results of “treatments of liver cancer” query task.
The liver domain was selected because the clinicians who collaborated in this study are liver experts, and the related research topics are relevant to the treatment of liver cancer. The degree of liver damage is a critical factor in the selection of appropriate treatment strategies. Therefore, query tasks related to the treatment strategies of liver cancer and classifying the degree of liver damage were selected to evaluate the functionality and performance of the proposed system.
The accuracy and the time performance of the system were evaluated using three medical query tasks relevant to liver cancer based on the clinical data generator in the experiments with various numbers of patients (ie, 10 patients, 100 patients, 1000 patients, and 10,000 patients). Among the three query tasks, one was selected from the treatment strategy of liver cancer, and the remaining two were selected from the classification of the degree of liver damage [
To examine a broad variety of patient data, the clinical data generator is implemented to automatically generate the clinical data in the repository, and the generated data are employed to evaluate the system. The clinical data generator automatically creates the data items by randomly setting the values and subsequently storing data items, such as information regarding laboratory test results and treatment procedures, in the clinical repository. For example, the laboratory test results for Prothrombin_Activity were randomly selected from a predetermined range. The clinical data generator created the patients’ clinical data, including the diagnosis information, laboratory test results, and treatment procedures.
Three query tasks (degree of liver damage, degree of liver damage when applying a mutually exclusive setting, and treatments for liver cancer) were involved in the experiments. Both the degree of liver damage query task and the degree of liver damage when applying a mutually exclusive setting query task contained a total of 4 GLIF3.5-formatted query criteria, and a total of 16 translated SQL-formatted query criteria, whereas the treatments for liver cancer query task comprised a total of 6 GLIF3.5-formatted query criteria and 6 translated SQL-formatted query criteria.
The distribution numbers of patients in four datasets that are randomly generated by the clinical data generator.
Dataseta | Degree of liver damage | Degree of liver damage when applying a mutually exclusive setting | Treatments for liver cancer |
#1 | Degree A: 1/10 | Degree A: 4/10 | LTb: 5/10 |
|
Degree B: 3/10 | Degree B: 7/10 | TACEc: 2/10 |
|
Degree C: 6/10 | Degree C: 6/10 | RFAd: 0/10 |
|
|
|
AIe: 3/10 |
|
|
|
SRf: 0/10 |
#2 | Degree A: 11/100 | Degree A: 52/100 | LTb: 22/100 |
|
Degree B: 36/100 | Degree B: 60/100 | TACEc: 23/100 |
|
Degree C: 53/100 | Degree C: 53/100 | RFAd: 21/100 |
|
|
|
AIe: 19/100 |
|
|
|
SRf:15/100 |
#3 | Degree A: 129/1000 | Degree A: 555/1000 | LTb: 195/1000 |
|
Degree B: 348/1000 | Degree B: 549/1000 | TACEc: 202/1000 |
|
Degree C: 523/1000 | Degree C: 523/1000 | RFAd: 191/1000 |
|
|
|
AIe: 206/1000 |
|
|
|
SRf: 206/1000 |
#4 | Degree A: 1258/10,000 | Degree A: 5298/10,000 | LTb: 1984/10,000 |
|
Degree B: 3409/10,000 | Degree B: 5477/10,000 | TACEc: 1970/10,000 |
|
Degree C: 5333/10,000 | Degree C: 5333/10,000 | RFAd: 2079/10,000 |
|
|
|
AIe: 1980/10,000 |
|
|
|
SRf: 1987/10,000 |
aThe datasets #1, #2, #3, and #4 are regarded as the datasets with different numbers of patients, including 10, 100, 1000, and 10,000 patients.
bLT: Liver transplantation.
cTACE: Transarterial embolization and chemoembolization.
dRFA: Radiofrequency ablation.
eAI: Alcohol injection.
fSR: Surgical resection.
In the experiments, the clinical data generator automatically generated various numbers of patients’ clinical data. Four datasets (ie, 10 patients, 100 patients, 1000 patients, and 10,000 patients) were generated randomly, and contained clinical data such as diagnosis data, laboratory test results, and treatment procedure data. The three query results of the three query tasks based on these four datasets were collected manually as the benchmark (ie, gold standard), against which the query results of the proposed system were compared to evaluate the accuracy of the proposed system. The accuracy of the three query tasks (ie, degree of liver damage, degree of liver damage when applying a mutually exclusive setting, and treatments for liver cancer) was 100% for all four experiments based on the four patient groups. This shows that the proposed system could perform all of the query operations accurately for the experiments.
The proposed system is an experimental version designed to test a novel methodology for building a query execution engine using FBDQMs by formulating query tasks using the existing GLIF. The proposed system was implemented based on Visual C# .NET, and Microsoft Silverlight technology was used to display the updated information dynamically during the data retrieval process. The system developed for this study is based on a Web-based architecture and is not provided as an open source. A new client-side user must install the Silverlight framework in the client-side computer to access the proposed system through a browser (eg, Internet Explorer or Google Chrome). For the server-side system, the database functions were provided by Microsoft SQL Server 2008. When the database was migrated (eg, from Microsoft SQL Server 2008 to Oracle), the programs relevant to data retrieval (eg, a program to retrieve data from a database based on specific SQL comments) must also be recoded.
The performance in time of the system in experiment with three query tasks.
Item (patient number) | Degree of liver damage (seconds) | Degree of liver damage when applying a mutually exclusive setting (seconds) | Treatments for liver cancer (seconds) |
SQL operations | 93.82% (1.427) | 92.60% (1.377) | 95.76% (0.474) |
Criteria verification | 0.46% (0.007) | 0.34% (0.005) | 0.61% (0.003) |
Other tasks | 5.72% (0.087) | 7.06% (0.105) | 3.64% (0.018) |
Total (10) | 100% (1.521) | 100% (1.487) | 100% (0.495) |
SQL operations | 93.82% (1.623) | 93.45% (1.542) | 95.99% (0.598) |
Criteria verification | 0.75% (0.013) | 0.55% (0.009) | 0.96% (0.006) |
Other tasks | 5.43% (0.094) | 6.00% (0.099) | 3.05% (0.019) |
Total (100) | 100% (1.730) | 100% (1.650) | 100% (0.623) |
SQL operations | 85.13% (2.221) | 84.22% (1.985) | 70.90% (0.675) |
Criteria verification | 11.46% (0.299) | 11.50% (0.271) | 26.79% (0.255) |
Other tasks | 3.41% (0.089) | 4.29% (0.101) | 2.31% (0.022) |
Total (1000) | 100% (2.609) | 100% (2.357) | 100% (0.952) |
SQL operations | 22.16% (8.124) | 24.75% (8.076) | 11.95% (2.750) |
Criteria verification | 77.60%(28.455) | 74.97% (24.461) | 87.96%(20.248) |
Other tasks | 0.24% (0.087) | 0.28% (0.092) | 0.10% (0.022) |
Total (10,000) | 100% (36.666) | 100% (32.630) | 100% (23.020) |
The performances of the system based on the three query tasks in four experiments with different number of patients, including a) degree of liver damage, b) degree of liver damage when applying a mutually exclusive setting, and c) treatments for liver cancer.
The results of the three query tasks show that when more query target patients are in the database, more total execution time is spent on the query operation. The phases that required the greatest length of execution time were the SQL operations and the criteria verification phases (
The proposed system simplified complex GLIF3.5-formatted query criteria into one or more SQL-based units. The complicated query criteria was verified during the criteria verification process after the patient sets were retrieved based on the simplified SQL queries during the SQL query process. Therefore, the increase in the execution time for the criteria verification process was greater than that for the SQL query process when the total number of patients increased.
For the query tasks when applying the mutually exclusive setting, once the patients had been verified and had met the criteria for the one-child nodes, the patients did not require further verification for the other child nodes. In this situation, less time was required to perform the criteria verification process. Therefore, the query task with the mutually exclusive setting required less time than those without applying the mutually exclusive setting (
The approach proposed in this study provides several beneficial features. First, the adoption of GLIF3.5 increases the potential for interoperability and shareability of database queries. This study was inspired by the work of GLIF3.5 and employed GLIF3.5 classes such as “algorithm” to formulate the query tasks. Thus, the benefits provided by GLIF3.5 can be inherited. GLIF3.5 is a clinical guideline representation language that was originally developed for formulating and sharing computer-interpretable clinical practice guidelines. The concepts, patient data items, and query criteria in the query tasks can be represented using standard vocabularies, medical data models, and medical logical expression languages of criteria (eg, the Unified Medical Language System, UMLS; HL-7’s Reference Information Model version 1.0, RIM; and Guideline Expression Language, GEL [
Second, GLIF3.5 contains flowchart-based models. The GLIF3.5 algorithm class is used to formulate the algorithm included in the clinical guidelines [
Austin et al in 2008 proposed a method for consistently querying one or more EMR systems based on many years of European research and standardization of the interoperable communication of EMRs [
A year later, Mabotuwana and Warren proposed a tool for displaying the prescription information of patients by employing visual timeline graphical charts and applying an ontology-driven approach for formulating query criteria [
In RetroGuide, a query task was formulated based on the flowchart using the workflow editor. Instead of employing medical-specific knowledge representation standards such as Asbru, EON, GLIF, and PROForma [
Although the query language generator and the clinical data retriever employed in this study can retrieve the clinical data by interpreting GLIF-formatted query tasks using the GLIF3.5 ontology interpreter, the components in this study do not function as a regular guideline execution engine. The components developed in this study provide functions for querying the clinical data based on specific criteria, although they do not function as a guideline execution engine for updating the medical decisions determined by clinicians. There is a prior published report on GLIF execution engine called GLEE [
Cohort identification is an essential process of clinical research. Previously, cohort identification approaches such as the informatics for integrating biology and the bedside (i2b2) hive [
Although this system enriches the capability of data querying using the ontology-driven and FBDQM-based approaches, it does present several limitations. First, the query criteria in nodes cannot be directly modified or created using the criteria selection interface. The query criteria must be formulated in advance using the GLIF3.5 format in Protégé. Subsequently, these criteria are exported in the XML format and are managed by the proposed system. If the query criteria in the node require modification, or if new criteria must be added in the node, the criteria should be modified or created using the Protégé environment.
Second, to perform the data mapping, the data item mapping table should be predefined in the database. The query language generator used the predefined mapping information to map the data items. During the mapping process, the data items in the query criteria are mapped to the data items in the database. When the mapping information is not predefined in the database, the mapping process might be performed incorrectly.
Third,
Fourth, although the proposed approach could assist users with limited database experience in formulating the query tasks, they must understand how to employ the GLIF3.5 components to formulate the query tasks.
The fifth limitation is related to the problem of common representation for patient parameters (eg, diagnoses, procedures, demographic data, and laboratory results). In this study, the data formulated using the GLIF are not mapped to the common representations, such as vMR [
Sixth, GELLO is an object-oriented query and expression language [
Seventh, this study has a limited set of examples related to the liver disease domain, and it is not been tested in numerous domains. When a mapping table (ie, the source data item is mapped to a destination data item in the local database) for other disease domains is defined, the system could be capable of managing query tasks for other diseases.
The eighth limitation is that this query platform is focused only on the cohort estimation counts (ie, patient counts). The query platform can be used for collecting patient IDs (ie, cohort) but not for cohort data (eg, cancer cohort with data on tumor size, survival, and laboratory values) in the dataset results. For example, it can solve problems involving the number of patients in the database with liver tumors measuring 2 cm or smaller and a range of value of a specific laboratory, but not a dataset on all liver cancer patients with the data on tumor size and this specific laboratory result.
GLIF as format is not being actively improved; GLIF3.5 is the current version. Furthermore, because the interpreter developed in this study was based on the GLIF schema, the method proposed in this study is useful only for interpreting query tasks formulated using the GLIF. Query tasks based on the GLIF are created using an interface provided by Protégé. This system is a laboratory experiment for presenting the feasibility of the methodology presented in this study. Users of the proposed system are both creators and key collaborators.
This experiment was conducted to evaluate the feasibility of applying a methodology used for building a query execution engine by formulating query tasks using the existing GLIF. The framework can be used in clinical research when a researcher must identify patients based on specific criteria. The framework could be enhanced further by retrieving both cohort and patient data (eg, structured data and relevant clinical narrative reports). Furthermore, because the query tasks were formulated using clinical guideline representation language, the framework can also be used to verify the status of guideline compliance by querying the patient data using an encoded guideline.
The FBDQM-based query execution engine comprises eight major components, including logical processing components and visual representation components. The proposed FBDQM-based query execution engine was implemented to interpret the XML-formatted query tasks that were formulated using GLIF3.5, execute the query operations, retrieve clinical data, and represent the query results. In the experiments involving different numbers of patients, the FBDQM-based query execution engine performed successfully in retrieving the clinical data based on the query tasks formatted using GLIF3.5.
The ontology-driven and FBDQM-based approach enriched the data query capabilities along the three major considerations: using the query interface for query task formulation, representing query results, and employing models to formulate query criteria. The potential for interoperability, shareability, and reusability of the query tasks was increased by adopting GLIF3.5.
The video file for demonstrating the proposed approach.
The link to YouTube video for the demonstration of the proposed study.
More information related to the formulation of query tasks using GLIF3.5 through Protégé and the translation of query tasks into the XML format document.
The XML file containing two examples of query tasks described in this paper. These query tasks are formulated using GLIF3.5 and translated into XML documents. These query tasks are only used for testing the performance of the proposed system and have not been validated medically by clinicians. They should only be seen as examples of query tasks encoded using GLIF3.5.
electronic medical record
flowchart-based data-querying model
Guideline Expression Language
GLIF execution engine
Guideline Interchange Format version 3.5
knowledge-data ontological mapper
Reference Information Model
Structured Query Language
Unified Medical Language System
Extensible Markup Language
XML Process Definition Language
The authors acknowledge the members of the research team lead by F Lai of National Taiwan University for their contributions toward this study.
The authors would also like to thank Professor Mor Peleg for her generous support in providing the materials related to GLIF.
F Lai received grants from the National Science Council, Taiwan (NSC 101-2221-E-002-203-MY3). The funding organizations were not involved in designing or conducting the study, evaluation, analysis, nor the preparation of the manuscript.
None declared.