Current status of ontologies in Biomedical and Clinical Informatics

Transcription

1 Current status of ontologies in Biomedical and Clinical Informatics Rishi Kanth Saripalle University of Connecticut, Storrs Abstract It is becoming an impossible task for managing research data in the field of biomedical and clinical informatics. These huge data sets cannot manually be analyzed, interpreted or processed to acquire inferred knowledge efficiently. We need intelligent agents or computer systems to help us in doing these tasks and hence it becomes mandatory to represent medical knowledge in computer process able format. Semantic technology and ontology can be used to partial solve the data management problem in medical informatics. Semantic knowledge representation allows the intelligent agents or computers to interpret the data and acquire inferred knowledge. Hence, ontology design is an important aspect of medical informatics, and reusability is a key issue that is determined by the level of compatibility among ontology concepts and among the theories of the biomedical domain. In this paper we will discuss the role of ontologies in representing medical informatics. First, we will talk about the principles of ontologies and few examples. Next we will study some fully developed biomedical ontologies and their differences. Finally, we study the applications of ontologies in biomedical research. Terms: Ontology, biomedical ontologies, medical informatics, clinical informatics, clinical decision support systems, knowledge representation, patient health record (PHR), clinical trials, Protégé, SNOMED-CT, GALEN, Gene Ontology (GO), Ontology integration, Ontology Mapping, NCodes. I. Introduction In the last few decades much research has been done in the field of biomedical informatics and voluminous amount of research data has been collected in the fields of clinical research, biomedical research, life sciences, gene research, patient records, clinical trials etc. Simultaneously various biomedical tools have been developed to perform wide range of function like data mining, data management, data collection etc. This in turn has forced scientists to analyze and structure the knowledge to make further inferences from the present knowledge. A survey conducted showed that DNA sequence databases have been doubling for every 18 months. Most of the existing databases have overlapped data as they are built independent to each other. Database systems today are facing the task of serving ever increasing amounts of data from growing complex user community which is getting more and more demanding. All the researchers need almost the same data but with different meaning or context. This makes semantics very important for this domain. II. Ontology Ontology - science of being" - typically has different meanings in different contexts. The word originated in philosophy where several philosophers - from Aristotle (4 th century) to Leibniz ( ), and more recently the 19th Century major ontologists like Bolzano, Brentano, Husserl and Frege have provided criteria for distinguishing between different kind of objects and the relations among them. The objects can be both concrete and abstract. In the late 20 th century, Artificial Intelligence (AI) adopted the term and began using it in the sense of a "specification of a conceptualization" in the context of knowledge and data sharing [1]. 2.1 Definition Ontology is hierarchal structuring of knowledge about concepts by sub-classing them 1

2 according to their properties and qualities [1]. It can also be defined as a declarative model of a domain that defines and represents the concepts existing in that domain, their attributes and the relationships between them [1] [2]. Ontology gives the description of concepts and the relations that can exist between them. The concept is very important for data sharing and knowledge representation. 2.2 Classification Ontology can be classified according to level of detailed knowledge they provide. Upper Ontologies provides very generic knowledge with low domain specific knowledge. For example, Disease ontology is upper ontology compatible for any biomedical domain. General ontologies represent knowledge at an intermediate level of detail independently of a specific task. Domain ontologies represent knowledge about a particular part of the world, such as medicine, and should reflect the underlying reality through a theory of the domain represented. For example, Gene Ontology, Finally, ontologies designed for specific tasks are called application ontologies. 2.2 Description We have defined ontology as specification of concepts and relation between them. In ontology, concepts of the domain are represented by classes. The features and attributes of the concept are described by properties or slots. Together with instances which are individual of a class it constitutes the knowledge base of the domain. Classes are the main focus in ontology. Classes can be sub-classed to describe more specific features of a class. For example, if we define a class Wines, it includes all the wine classes in the wine domain. The wine class can be sub-classed to specify more specific wines like Red Wine, White Wine etc. Instances are individuals related to a same class. For example, Australian Yellow Tail is an individual for Wine class. Slots or Properties can be created to describe properties of a class or instance. For example, we can define a property named Has_Color which holds the color of a particular wine class or instance. The figure 1 shows the summary of the above discussion. Therefore in particular describing a domain in ontology includes [3]: 1. Defining the concepts of the domain as classes. 2. Defining the individuals of the class as instances. 3. Defining the attributes of the individuals as properties 4. Filling the properties values for the instances. Figure 1: Describing Australian Yellow Tail Wine instance and filling property values 2.3 Advantages: Ontologies are developed and defined to share the knowledge among the researchers working on the same domain. The main reasons for developing ontology are [3][4]: 1. Sharing the knowledge in the same domain is one of the common goal for which ontologies are developed. For example, many websites provide medical information about various concepts in the medical domain. If they use the same medical terms for describing the information, the data can be integrated easily from different sources by the computer agents and solve the user queries. 2. To reuse the already build ontology is the recent tide in the ontology research. For example, the notation of capturing time has become important 2

3 in different domains especially in the medical domain. The notation of time includes time intervals, time of event occurrence, interval between events etc. If a group of researchers define an ontology which includes all these features, other research groups can simply import the existing ontology for serving the purpose. 3. To separate domain knowledge from operation knowledge. For example, we can describe a task of configuring a product from its components according to a required specification and implement a program that does this configuration independent of the products and components themselves. We can then develop ontology of PC-components and characteristics and apply the algorithm to configure made-to-order PCs. We can also use the same algorithm to configure elevators if we feed elevator component ontology to it. The fundamental rules that should be in mind when developing ontology should be: 1. There is more then one way to define the same working domain. The best solution always depends on the application where the ontology is deployed. 2. Development of ontology is iterative process. 3. Before developing the ontology, the working domain range should be specified. This will give the scope of the ontology. Consider reusing the ontology. It s better to look into others work in the domain to see if we can directly use the ontology or refinement to the ontology can solve the problem. 2.4 Importance in Biomedical informatics Community. Most of the research data is distributed across various heterogeneous databases and architecture. The development of individual databases has generated wide variety of formats for implementation. Attempts are made to unify different data formats, but none of them proved to be reliable. Database integration is very costly operation and also need huge resources. It is becoming very difficult for the clinical researchers to gather the required data. There is consensus that a common language, or at least a mutual intelligibility would be a good first step, but this goal has proved difficult to achieve. Most of the public databases have emerged out of necessity from work that scientist, unfamiliar with data and knowledge representation standards have done in isolation. Because of the inconsistence among the research data formats it is been very difficult to develop generic computer algorithms for interpreting the data. The databases describe objects according to the database schema, not giving general concepts and their relation between them in various contexts. At this alarming stage, researchers are tending to represent knowledge of their domain in an independent format so that data can be shared and reused across various platforms. This problem can be solved by semantics, RDF and OWL up to certain limit, as they provide common metadata and ontology language. Ontology provides a common framework for structured knowledge representation of domain knowledge. Ontology framework provides common vocabulary for concepts- in this case biomedical concepts, concept definitions, relationships, axioms and rules- allow a controlled flow of knowledge into the knowledge base. Ontology reasoners help researchers by mining inferred knowledge from the knowledge represented in the ontology. III. Present Biomedical Ontologies For the past few years numerous ontologies have been developed in biomedical community with a soul aim, to represent biomedical terminology in a common vocabulary so that they can be shared and reused across various fields. In the previous section ontology can be classified according to level of detailed knowledge they provide: Upper Ontologies, General ontologies, Domain ontologies application ontologies. In this section we will discuss some of the most powerful ontology in biomedical and clinical domains. These ontologies are developed by various medical centers, researchers, industries etc. 3

4 3.1 OpenCyc Open Cyc is an Upper level ontology developed by Cycorp Inc. This project was started in 1984, has thousands of hand coded assertions that capture common sense language. AI algorithms can perform human like reasoning on these assertions. OpenCyc is a upper level ontology, with 6,000 concepts and 60,000 assertions about those concepts[5][6]. Cancer, malignant neoplastic disease: any malignant growth or tumor caused by abnormal and uncontrolled cell division; it may spread to other parts of the body through the lymphatic system or the blood stream Cancer, Crab: (astrology) a person who is born while the sun is in Cancer Cancer: a small zodiacal constellation in the northern hemisphere; between Leo and Gemini Cancer, Cancer the Crab, Crab: the fourth sign of the zodiac; the sun is in this sign from about June 21 to July 22 Cancer, genus Cancer: type genus of the family Cancridae Figure 2: OpenCyc top-level ontology The figure 2 shown above illustrates OpenCyc ontology with Thing as universal set of collections. 3.2 WordNet WordNet is an electronic lexical database developed at Princeton University that serves as a resource for applications in natural language processing and information retrieval [5]. The core structure in WordNet is a set of synonyms (Sysnet) that represents one underlying concept. Synset formation is based on synonymy (one meaning expressed by several words) and polysemy (one word having several distinct meanings). WordNet has been influenced by cognitive psychology as well as linguistics, and its hierarchies are not based on formal ontology theory [7]. Many concepts that represent health disorders in medical terminologies, when present in WordNet, are categorized appropriately. For example, when keyword cancer has the following meaning in WordNet: 3.3 GALEN GALEN stands for Generalised Architecture for Languages, Encyclopedia and Nomenclature in Medicine, is a European project developed for reuse of terminology in clinical systems [5]. GALEN evolved from the knowledge-based terminology of Alan Rector s Pen&Pad electronic medical record system. Most of traditional terminologies are precoordinated in the knowledge structure, but GALEN provides the terminology for building blocks of describing the terminology. For example, the concepts Adenocyte and Thyroid gland are present in GALEN. However, instead of providing an explicit representation for Adenocyte of thyroid gland, GALEN indicates that it can be described by a combination of concepts as, Adenocyte which < is structural component of Thyroid gland >. In 2000, an open source foundation called OpenGALEN was established to distribute the reference model free and work with software vendors and terminology developers to support its extension and use. Since then, the Galen model has been used to study nursing terminologies, decision support knowledge, surgical procedure, and anatomy. The figure 3 shown below illustrates the top-level hierarchy of GALEN ontology [5]. 4

5 Figure 4: UMLS Metathesaurus and Semantic Network Figure 3: GALEN top-level ontology 3.4 UMLS UMLS acronym for Unifies Medical Language System was developed by National Library of Medicine. UMLS identifies any entry into three groups: string representing a term as terminology. Lexical Group strings of same structure can be mapped. Concept - string of identical meaning. [6][8] UMLS is divided into three groups: Metathesaurus, Semantic Network, and Special Lexicons. The metathesaurus will hold all the biological terms in the database. The Semantic Network connects different terms in the metathesaurus semantically. The Semantic Network consists of 135 semantic types, organized into a pair of hierarchies with 6,864 relations among them. The relations show how different semantic types are related to each other. The figure shown below shows the relation between the two layers of UMLS. The knowledge is represented by actual instances of relations between actual concepts. The figure 4 shown above illustrates the communication between UMLS layers. For example, Disease is semantic type with around 392 relations (109 semantic relations and 22 other relations). Pneumonia categorized under one semantic type Disease, but has hundreds of relations. The figure below shows the two-level structure of UMLS. The UMLS has probably a greater impact on biomedical ontology work than any other terminology effort because of its long history, its early focus on knowledge representation and its free availability. 3.5 SNOMED- CT SNOMED stands for Systemized Nomenclature Of Medicine Clinical Terms. SNOMED-CT is the result of merging two ontologies: SNOMED-RT and Clinical Terms. SNOMED CT is the most comprehensive biomedical terminology recently developed in native description logic formalism [6]. Figure 5: SNOMED-CT ontology classification 5

6 3.6 FMA Foundational Model of Anatomy was developed and maintained by university of Washington. FMA structural represents knowledge about human anatomy. This model was developed to enhance the anatomy content of UMLS. Figure below shows the top level structure of FMA. 3.7 Gene Ontology Gene Ontology (GO) is a controlled biological terminology being created by a consortium of bioinfomaticians. Even though it s relatively new to the world when compared to other ontologies, GO has greater impact on bioinformatics community. GO started with terminologies from three genomic databases: Flybase, Saccharomyces Genome Database and Mouse Genome Database and has developed three hierarchies of terms to describe biological processes, cellular components and molecular functions. Gene definitions and comments by the authors are given as annotations in the ontology. Body fluids also include Sweat and Semen, as well as Lymph and Pus. 4.1 Ontology Integration As discussed, one of the primary advantages of using ontologies is to reuse the described knowledge. When using already developed ontology to construct new domain ontology, factors like data heterogeneity, concepts mismatch, and composition of ontology etc must be kept in mind. Ontology Integration can widely mean integrating, merging, extending etc [9]. Practical integration problems are faced when trying to merge two existing ontology describing the same domain concepts. In contrast they are different levels of integration: alignment, partial compatibility and unification. Unification is synonymous with merging. The alignment means a mapping of concepts and relations between multiple ontologies based on preservation of the partial ordering and synonyms, as well as the possible introduction of new concepts that will function as sub-types or supertypes. The figure 6 shown below illustrates ontology integration. IV. Compatible issues with Ontologies. All the above discussed ontologies have a common aim, to represent medical or clinical information in ontology. However, all the above ontologies describe the same domain, but classify and describe the same concept in different ways. Let us examine how these ontologies classify and describe the concept Blood in their domain. What makes us discuss the concept Blood is its dual nature, both as tissue and fluid [5]. In WordNet, Blood is defined as fluid that is pumped by the heart. There are five other ways in which Blood is described in WordNet. In GALEN blood is classified under Soft Tissue, Lymphoid Tissue, Integument and Erectile Tissue. All the above classifications are under a general class Substance. GALEN describes Blood as physical structure rather than a bodily fluid. In SNOMED CT, Blood is found in the category Substance as a child of Blood material, and Blood component. Multiple inheritances allow Body fluid, an ancestor of Blood, to inherit from both Body substance and Liquid substance. These two concepts are children of the top level category Substance. Ontology B Ontology AB Ontology A Integration Figure 6: Onotlogy Integration As we are trying to merge or integrate different ontologies, we can have two types of integrations: Semantic Integration and Structural Integration [9]. In the semantic integration, we will be focusing on meaning of the concepts. Structural integration comes into play when the semantics of the two concepts agree and now we need to organize these concepts. These integration problems arise when 6

7 integrating two ontologies of same domain or complementary domain where many concepts overlap with each other. PART-OF relationships. The figure 8 given below shows the mapping between the concepts of different ontologies. 4.2 OASIS: Integration Framework OASIS presents a framework for mapping and integration of heterogeneous biomedical ontologies. The framework detects possible false mappings and provides intuitive interfaces for users to customize mappings and for applications to integrate and access biomedical ontologies. The figure 7 [10] shown below illustrates the ontology integration framework. Figure 7: OASIS: Ontology Integration framework Oasis is based on the existing database for Open Biomedical Ontologies (OBO). Ontologies in Oasis are mapped to each other through mappings stored in a table. Oasis also provides a mapping generation tool, called Interactive Ontology Mapping Generator (IOMG), for users to generate and customize the mappings. The figure below shows the architecture of Oasis integration framework. The ontology database has all the required terminologies and supporting meta-data information. The mapping tool with the support from the mapping table constructs the semantic correspondence between the terms. The terms in the OBO are arranged in Directed Acyclic Graph (DAG), which allows multiple parents to the child nodes. The arcs in the graph represent IS-A or Figure 8: Mapping of concepts from Ontology A to Ontology B The IOMG [10] algorithm initially calculates the similarity value between the terms. The similarity values are obtained by using: Linguistics Similarity, Definition Similarity, and Neighbor Similarity. The figure 10 shows the formulae for calculating the similarity between the terms. In the Linguistics Similarity, the composition of the string is compared with one another terms. The synonyms database tables are taken into consideration during evaluation. Definition Similarity, the definition of two terms is compared to find the similarity value. This technique uses a text classification algorithm between two terms. In Neighbor Similarity, the parents and children of the two terms are compared. The probability of obtaining similarities when neighbors are compared is very high. The algorithm uses the above discussed metrics and specified formulae for obtaining the similarity value. Figure 10: Similarity formulae used in OASIS to find similarity between the terms Hence, given two ontologies O 1 and O 2 with M and N terms respectively, the Sim(m,n) is calculated. The values whose range is below a threshold value are discarded. 7

8 V. Applications of Ontology We have seen different powerful ontologies developed by clinical researchers. Ontologies provide the advantage of giving semantic meaning to knowledge. In this section we will explore the applicability of ontologies and semantic technology in the medical domain. 5.1 Retrieving Patient Records for Clinical Trials. As the growth in bioinformatics research is tremendously increasing, physicians are banking on research and evidence based practices for medical care. But however, a major setback in clinical and translational research is low patient participation in clinical trials. Presently, matching clinical trials to patient data is manual and tedious. This section investigates is there a feasible solution for automating this process i.e finding out patients who match the clinical trials criteria. This section uses SNOMED-CT ontology as knowledge base. The major obstruction in this automating process is the raw patient data. This architecture must implement a semantic network to connect different sections. The architecture [11] for the application is shown in the figure 11 below. Patient Data ABox Clinical Trials Query Ontology Reasoner SNOMED- CT TBox Figure 11: Architecture for retrieving patient records which match clinical trials The clinical trial inputs are given as input to the system. As the system has the semantic representation of the given clinical trial, the query is given to the reasoners in-order to execute the query against both the patient data and knowledge base. The key challenges which the engineers face are: knowledge engineering, scalability and noisy data. Knowledge engineering involves integration of imported clinical ontology with medical center technical terms and construct rules from raw patient data. The problems faced can be, for example: SNOMED-CT is the imported ontology in this application, describes generic drugs concepts with their active compositions. But, patient records have vendor specific drugs without any particular composition specified. The ontology describes the organism, caustic agent causing the disorder etc. The patient records only specify the result of the tests and location at which the tests were performed. Hence the application needs mapping layer to allow communication between ontology and patient data Reasoners are used against the ontologies that are very large to retrieve the information. A combination of TBox and ABox reasoners must be used for the application. Finally the most common challenge for knowledge engineers: Noisy or incomplete data. Clinical data is inconsistent. The reasoner assumes the data against which it s acting to be consistent. Hence data cleaning must be done efficiently. However engineers have figured out ways to overcome these challenges by using basic techniques and principals. As we have seen there are two taxonomies involved MED and SNOMED-CT that are at different levels [11]. MED is a semantic framework used for terminology encoding at the medical center. A semantic mapping is required to use both of them together. MED has 100,212 concepts while SNOMED-CT has 379,630. It makes logical sense to map MED to SNOMED-CT ontology. It can be difficult to match MED to SNOMED-CT directly, to resolve the issue we can use third party ontology like UMLS for the mapping. The patient records have vendor specific drugs that must be mapped to SNOMED-CT ontology. The next step would be converting the raw patient data into semantic assertions. A set of transformation rules have been developed which 8

9 convert patient database records into semantic format. The negative results in the patient records are taken care by logical negation. For example, the following patient record statement can be converted into an assertion: CernerDrug: Lactulose Syrup 20G/30ml Individual p: admisnisteredsubstance Lactulose. The figure 12 and figure 13 shown below will show some of the transformation rules and patient assertions used in the application respectively[11]. Figure 12: Transformation rules for Radiology Events to Abox assertions. But the SNOMED-CT ontology will have detailed information about the InfAB. Due to this mismatch the reasoner may not infer or query the knowledge correctly. Hence to avoid this difficulty the user can specify what exactly he/she is searching for in the knowledge base. Using an year patient data from the medical center, a total of 22,561 TBox subclasses, 26 million assertions were formed. One feasible conclusion that can be formed is that we can automate the process of querying the patient records for clinical trials. 5.2 Randomized Clinical Trials Randomized Clinical Trials are the unbiased clinical research results that can have high influence on clinical evidence based practices [12]. It is becoming increasing evident that physicians are highly driven by evidence base practices rather than self-learned experienced knowledge. The knowledge of evidence based practices is highly demanding as it is the major fuel, which drives clinical decision support subsystem. We will see more details about clinical decision support system in the next section. The researchers are contributing innovative ideas for solving medical informatics problems which are all published on paper. This section proposes that the research findings can be formatted in a machine understandable for intelligent agents to process and infer knowledge. The figure14 below shows the life cycle of clinical trial. Figure 13: Radiology patient event rules Therefore establishing a semantic bridge between knowledge different components can solve knowledge engineering problems. The patient data is incomplete and inconsistent for semantic assertions to act on it. The patient records state whether the patient has been tested positive for a infection say InfAB or not. Figure 14: Clinical Trials life cycle. 9

10 The RCT must be analyzed, interpreted for various patients that can take long time for the evidence to convert into action. For processing the information more efficiently and fastly, the data must be converted into computer understandable format and also AI agents can understand it. Hence the RCT are encoded into ontology. The ontology is constructed using Competency Decomposition. The task of constructing the ontology is divided into sub tasks. This process of decomposition is repeated until we reach the base case, where we will have the concrete information for completing the sub task. Clinical Trial Reports and Clinical Databases provide the necessary structural specifications for the ontology. Even though the clinical reports are inconsistent or have incomplete data structure, clinical reports are considered. Based upon the specifications, RCT schema constructed has 188 Frames and 601 Slots [12]. The RCT concept hierarchy is as show in the figure15 below: Figure 15: Randomized Clinical Trials Ontology Schema The RCT schema was successfully implemented which could capture almost all clinical trials except for some exceptions. The schema could not capture nested group tags. Some of the properties are not machine understandable. We showed that RCT Schema is competent for the vast majority of systematic reviewing subtasks and that it has performed well in capturing a range of RCTs. RCT schema is one of the most complete ontology for trials interpretation and application for heath care systems. 5.3 Clinical Decision Support System The clinical decision support system (CDSS) can be defined as interactive computer programs, which are designed to assist physicians and other health professionals with decision making tasks [13]. It can also be defined as "Clinical Decision Support systems link health observations with health knowledge to influence health choices by clinicians for improved health care"[13][14]. Achieving perfection in providing good health care by physicians is very complex and perplexing. This condition becomes worse when physicians have limited knowledge about the working domain or are working under emergency conditions. With the advances in expert systems, rule engines, case base systems and through combination with advanced methods of information retrieval, information storage, knowledge representation, a decision support system can be designed which will aid novice nurses during their regular practice. For implementing a CDSS we need to have the following components: 1. Knowledge Base this acts as a brain to your application. 2. Rule Base Engine this engine will hold rules for your application. 3. Business Model this model will be responsible for talking to various components and inter-connecting them. 4. UI possible user interface so that user can interact with the application. The typical architecture of the CDSS is shown in the figure 16 below [13]. The figure shows how each component communicates with each other in the application. Figure 16: Clinical Decision Support System Architecture 10

11 The Clinical Repository or knowledge base will hold all the application specific patient clinical data, external data, business models etc. The Rule engine holds all the rules used in the application. A rule engine can be thought of as an set of IF-THEN statement which will lead the path to an action or another rule. For example IF RULE 1 THEN ACTION 1 IF RULE 2 THEN ACTION 2 IF RULE 3 THEN ACTION 3 IF RULE 4 THEN RULE 1 This can be represented in business model as: IF patient.age()==34 IF patient.hbp()<=230 IF patient.insulin()==24 THEN patient.intervation()== ECG Test The same rules can be represented as axioms in the ontology as: Now depending upon the user query the rules in the system can be fired to perform an action. Let us consider Nursing COmputer Decision Support System (NCODES) as a case study for CDSS [15]. NCodes is an intelligent system built for assisting novice nurses in making decisions by obtaining, evaluating and estimating patient conditions. NCodes provides online diagnosis, interventions, and assessment tools. The workflow architecture for NCodes is shown in the figure17 below: The hardware of the architecture involves LAN and PDA. The user gives in the input to the system through the PDA which is converted into an XML format and sent to the server side through wireless LAN [15]. Patient [[ gender.{ male } lasthdl.hdllessthan40] [[ Age.{50} HBP. LessThan230] Figure 17: NCODES workflow diagram. The knowledge engine executes the query and sends back the results in an XML which is parsed to display the results. The detailed architecture and components of the NCodes is shown the figure18 below [15][16]. The communication between various components is through XML. XML is chosen as its platform independent. [[ Insulin. LessThan24] 11

12 SELECT DISTINCT?x WHERE{?x URI:Has_LabResult URI:Low_sao2, URI:High_bp, URI:Low_ci}". The SPARQL queries are similar to SQL queries structurally but vary semantically. The worst case performance of using ontology with SPARQL is equivalent to average case performance of MS SQL Server. However much testing could not be performed to completely replace MS SQL Server with ontology. SPARQL language was recently developed in 2004 and the stability of language could be tested on huge ontologies. Figure 18: NCODES Architecture The knowledge base and the Rule Engine for this application are stored in MS SQL Server. Now the question will be can we use Ontology Knowledge base for querying the results? We can use disease ontology as knowledge base and query the ontology according the user input. SPARQL language can be used for query the ontology. SPARQL is a query language used against the RDF data graphs directly. SPARQL is an acronym for SPARQL Protocol and RDF Query Language. The ontology was created by using Protégé tool in Web Ontology Language (OWL) format. OWL is a super-class to RDF. RDF stands for Resource Description Framework. For example, "PREFIX URI: < PREFIX RDFS: < PREFIX OWL: < PREFIX XSD: < PREFIX RDF: < rdf-syntax-ns#> In the present architecture the queries and the results are passed through wireless LAN in XML format. Hence the performance of the system also depends on the wireless network performance, stability and efficiency. This also makes the architecture dependent on wireless LAN, when failed the systems goes down. The ontology file developed with hundreds of concepts is few kilobytes while the database will have size of megabytes. Hence we can load the ontology file in the PDA which makes it a local search and hence making it less dependent on the wireless LAN. The possibility of using ontology as backbone for clinical decision support system is feasible solution. Summary Semantic technology can partial solve the medical informatics problem by providing semantics to biological terms. The biomedical application like CDSS, medical language processing can be benefited from these ontologies. Even though researchers have developed medical ontologies, they have compatibility issues when used together. Rules can be encoded as ontology axioms and we can infer knowledge by executing them against the semantic medical data. Ontology can be queered using SPARQL language. Ontologies have a long bright road ahead in biomedical and clinical informatics. Future Work Even though many innovative brains are working to develop a formal model of ontology for 12

13 medical informatics, the semantic crossover between biomedical and computer is still missing. More over we have seen there is no agreement on an upper level ontology to which biomedical ontology could plug its concepts. Second, there is no unique prospective on a given domain, and some characteristics of biomedicine make it particularly difficult to represent. After much advancement in language technology, databases are developed to store biological terms. Mining scientific data from huge data repositories is tedious process. In 21 st century where computers are part of the human system, still some physicians prefer to go with text prescriptions and study material. Even with recent text extraction algorithm on biomedical literature, the results are not satisfactory. After many years of ontology language development, ontologies are still novice in the field of biomedical informatics. References: [1] Gruber, T. R, Toward principles for the design of ontologies used for knowledge sharing, International Journal Human- Computer Studies Vol. 43, Issues 5-6, Novemer 1995, Pages: [2] Nicola Guarino, Formal Ontology and Information Systems, Formal Ontology in Information Systems, Proceedings of FOIS 98, Trento, Italy, 6-8 June [3] Natalya F. Noy, Deborah L. McGuinness, Ontology Development 101: A Guide to Creating Your First Ontology, Stanford University, [4] Paul E. van der Vet and Nicolaas J.I. Mars, Bottom-Up Construction of Ontologies, IEEE Transactions on Knowledge and Data Engineering,Volume.10, No. 4, uly/august1998. [5] Olivier Bodenreider and Anita Burgun, Biomedical Ontologies, Springer-Verlag; p [6] [7] [8] [9] C. Maria (Marijke) Keet, Aspects of Ontology Integration, School of Computing, Napier University, February [10] Guanglei Song, Yu Qian, Ying Liu, Kang Zhang Oasis: a Mapping and Integration Framework for Biomedical Ontologies, 19th IEEE Symposium on Computer-Based Medical Systems, [11] Chintan Patel, James ciminio, Juilan Dobly, Achille Fokoue, Aditya kalyanpur, Li Ma, Edith Schonberg, Kavitha Srinivas, Aaron Kershanbaum, Matching patient records to clinical trials using ontologies, IBM Research Report. [12] Ida Sim, Ben Olasov, and Simona Carini, An ontology of randomized controlled trials for evidence-based practice: content specification and evaluation using the competency decomposition method, Journal of Biomedical Informatics 37 (2004) [13] Vipul Kashyapa, Alfredo Moralesb, Tonya Hongsermeiera, On Implementing Clinical Decision Support: Achieving Scalability and Maintainability by Combining Business Rules and Ontologies. [14] [15] P.Fortier, S.Jagannathan, H.Michel, N.Dluhy, E.Oneill, Development of a Hand-held Real time Decision Support Aid for Clinical Care Nursing, Proceeding 36 th Hawaii International Conference on System Sciences, IEEE [16] P.Fortier, B.Sarangarajan, H.Michel, N.Dluhy, E.Oneill, A Compterized Decision Support Aid for Clinical care Novice Nursing, Proceeding 38 th Hawaii International Conference on System Sciences, IEEE [17] Ruben Prieto-Diaz, A Faceted Approach to Building Ontologies, Information Reuse and Integration, IEEE International Conference October 2003, Pages:

14 [18] Amandeep S. Sidhu, Tharam S. Dillon, and Elizabeth Chang, Current Status of Biomedical Ontologies: Developments in 2006, 2007 [19] Natalya F. Noy, Daniel L. Rubin, and Mark A. Musen, Making Biomedical Ontologies and Ontology Repositories Work Stanford University, IEEE INTELLIGENT SYSTEMS. [20] Stefan Schulz and Holger Stenzhorn, Ten Theses on Clinical Ontologies, Department of Medical Informatics, Freiburg University Hospital, Germany. [21] J. J. Cimino, X. Zhu, The Practical Impact of Ontologies on Biomedical Informatics, IMIA Yearbook of Medical Informatics