2.1 Purpose of HealthAgent domain ontology

Ontology, in the philosophical sense, is the study of what is—entities and the relationships among the entities. Basically, it tries to answer questions such as ‘what exists or can exist in the domain of discourse?’ and ‘what are the relations between the objects in the domain of discourse?’. This view of ontologies has been revised and modified by the knowledge engineering and artificial intelligence communities in order to fit better with the goals of knowledge acquisition and knowledge management. In knowledge management, an ontology is a compendium of organized terms and concepts that drive actions, and has a praxis-oriented structure. In knowledge acquisition of the domain specifics, they reflect the epistemological stance that the knowledge engineer takes up in completing this task. In either form, a standard definition—an explicit, consensual specification of a conceptualization of a domain (Gruber, Reference Gruber1993)—provides a suitable working definition. In this paper, we do not commit to what an ontology is, but merely how it is that an ontology circumscribes what may be used in the HA system. Following Quine (Reference Quine1953), we state that ‘to be is to be the value of a bound variable’, but the variable is very much a part of the symbolic order of the software system, and despite its declarative formal foundation, this representation is given meaning in use. Glimpses of this approach show up in mapping issues discussed in the paper, in retrieving answers to queries (binding variables in quantifiers) and so on. As such, in this project we eschew refinements and extensions of upper-level ontologies in favour of a more pragmatic approach of ensuring that the declarative framework met the requirements of an application domain, and the validation that we sought was framed in that context. Indeed, the adequacy of the representation scheme, its fidelity to the relevant parts of (say) the neurooncological domain as conceived by its practitioners, rests upon the interpretations it supports and promotes in the context of clinical practice.

The Hadom follows this more opportunistic approach to defining ‘things’ in HA. In other words, Hadom captures the expertise and information necessary to facilitate diagnosis and prognosis of different types of brain tumours and management issues of brain tumour patients. Such knowledge is elicited and formalized in a machine-processable manner and with explicit definitions, providing the ground on which consensus can be described and verified. This is particularly important for a distributed environment such as the one envisioned by HA, since it is not rare in such environments for a meaningful conclusion to be drawn upon suggestions and observations by experts with different background knowledge and using different terminology.

Although the inclusion of clinical practitioners in system usage serves to ratify the faithfulness of domain representation, its use among software agents to facilitate interoperability requires stringent regimentation. Software agents and human users share the load of encoded pattern recognition and diagnosis. Hence, the knowledge representation scheme needs to be both expressive and sound, (cf. the above discussion on OWL). When we give instructions to software agents and when software agents communicate with each other, Hadom specifies the terms of reference in the language spoken by all participants to convey the intended messages. Examples of such conversations are ‘retrieve cases of all patients under 5 years of age’ and ‘fetch a case of glioma from Hospital A’, where the underlined words are concepts from Hadom.

A domain ontology, however, is not sufficient for establishing consensus among software agents. Hadom defines what software agents talk to each other about, but not how they talk—how the messages are composed, what speech acts are accommodated and so on. This is beyond the scope of a domain ontology. In HA, a separate ontology defines the concrete means for passing the information encoded with Hadom. This communication language (hal) defines the format of different types of messages that are sent back and forth among agents, parameters that are necessary to reconstruct agent behaviour, the encoding and decoding methods for extracting information from such messages and house-keeping information with respect to messages. For instance, a classifier agent might submit an instance of Database_Request_Msg to a DB handling agent to ‘retrieve a validated case with features X, Y and Z’. How the message itself is interpreted is regulated by hal, while the actual content—‘retrieve a validated case’ with the specified features—would be composed using instances of Hadom.

In practice, each agent is equipped with an ontology parser to understand the domain ontology. Upon receiving a request, the agent first consults Hadom for the meaning of the different terms that appear in the request. It then carries out the tasks that it is instructed to perform (e.g. retrieving data from a DB, classifying data against a set of labels, etc.). When it finishes, the agent composes an answer/response to the request, again using concepts defined in Hadom.

Hadom benefits from the reasoning capabilities inherent in the selected knowledge representation and reasoning formalisms. A DL-based formalism provides an automated subsumption-based inference; for example, Melanocytic Tumour is a sub-category of Meningeal Tumour. Hence, an instance of the former type would automatically inherit the characteristics and constraints of Meningeal Tumour. Hadom, however, does not contain knowledge of problem-solving methods. That is to say, the domain ontology only captures the static model rather than the inference procedures. Typical examples of the former are ‘patient’, ‘a particular type of tumour’, ‘MRS scans with their parameters’, etc., while examples of the latter are ‘due to the fact that … the tumour is malignant’ or when referring to MR spectra, ‘all peak areas with … characteristics suggest …‘Such separation is based on both theoretical and practical considerations. On the one hand, such inferences are built using hand-crafted rules, machine-learning techniques, etc. which, currently, are not ready to be built into a declarative knowledge representation formalism. On the other hand, a medical diagnosis is typically a complicated process with ambiguity and uncertainty for which a framework of logical inference that is streamlined for taxonomic knowledge is hardly adequate (Rector, Reference Rector1999). This, however, does not preclude building a reasoning system on top of Hadom; indeed the classification tasks within HA exemplify the use of non-deductive reasoning, while being grounded in terms for which a deductive, declarative formalism has been created. Other reasoning mechanisms, based on ontological concepts could be used to switch between different classification protocols. For instance, if certain patterns are present in a patient's MRI and/or MRS scans, an inference may be made to suggest the use of pattern-specific classifiers and even exclude certain possibilities from the final diagnosis if they are eliminated by clinical knowledge or perhaps an oncologist's understanding of the nature of the biochemical pathways involved. Such reasoning systems should rely on Hadom to express the underlying knowledge model and should be developed in close collaboration with clinical specialists, a task we have made preliminary investigations into, but have not integrated into the current implementation.

2.2 Structure of HealthAgent domain ontology

Hadom defines information related to brain tumours (and tumours affecting the central nervous system (CNS); e.g. brain tumour diagnosis, prognosis, patient management, etc.) in the context of the HA project. The primary goal of Hadom is to address the functionalities that are envisioned in HA and to successfully achieve such functionalities. The HA project has been strongly influenced by several other projects, namely, INTERPRETFootnote 8 and eTUMOURFootnote 9. The impact of these two projects on HA is reflected in the legacy terms in Hadom that facilitate a smooth migration of INTERPRET data into HA DBs.

Hadom comprises several relatively independent modules, each focusing on a particular aspect of diagnosing brain tumours. Figure 3(a) indicates the dependability among different modules. For instance, medical control consists of five medical imaging modules; diagnosis relies on anatomic information, CNS tumour types (based on the World Health Organization's (WHO) CNS tumour classification), symptoms and results from medical controls. Some top-level concepts of Hadom are listed here and certain concepts will be detailed in the following sections. When defining the conceptual structure and concept names of Hadom, we worked very closely (ontology validation meetings every 3 months throughout the whole duration of the project, joint demo programming workshops every 6 months, etc.) with domain experts, such as neurosurgeons, biochemistsand oncologists, to build up the picture of how a person is first recommended to the hospital, how he/she goes through all the medical examinations and tests, how knowledge from different domains is projected onto this patient and how a patient is managed during his/her treatment. The multiple domains of expertise—from neurooncology, medical imaging and spectroscopy, gene expression, and so on—address different levels and scales, both temporally and spatially. As such, tying together the knowledge modelling of each of the domains into a single domain ontology would require bridging relationships that are placeholders for as yet unspecified scientifically validated explanations. In this context, patient identity offers a conceptual handle as a site for knowledge integration, wherein these multiple discourses bear meaning in the context of aetiology and progression of a type of disease (Mol, Reference Mol2003). Thus, a meta-level organizing structure for the ontology can be viewed as a star-shaped graph with Patient_Record (Figure 3(b)) at the centre linking together all the related information about the patient coming from different domains of specialism. Again, such a choice for knowledge modelling is influenced by the nature of clinical practice, rather than a description of knowledge about cells and tissues from physiological and spatio-anatomical perspectives. The latter, the physical reality of biomedicine might have had a closer fit to the sense of ontology as a study of ‘what exists’, as the underlying, causal organizsers of medical intervention and management protocols.

Figure 3

Conceptual structures of HealthAgent domain ontology: (a) dependency of clinical concepts in Hadom (b) neighbours of Patient_Record

• • Patient_Record also known as electronic health record (EHR) is the most important concept in Hadom. It acts as an entry point into the ontology, especially when the task of rendering information onto graphical user interfaces (GUIs) is undertaken. It connects a particular patient to his/her examinations, diagnosis, treatment, prognosis, etc.

• • Patient is introduced to establish links between current EHR with chronological or historical records. It holds the necessary information about a patient needed for the purpose of diagnosis, treatment, and patient management. It can also facilitate the anonymisation process by creating a unique URI for a patient without exposing his/her identity.

• • Symptom is defined with attributes has_date and has_description. An instance of Symptom should be referred to by instances of Patient_Record when the symptoms of a patient should be recorded.

• • Clinical_Centre is referred to by the instance of Patient_Record. Information about clinical centres becomes necessary when the origin of the medical examination data should be recorded.

• • Clinical_Intervention is introduced to be compliant with the INTERPRET and/or eTUMOUR DB schemata. Clinical_Intervention is the parent concept of various methods used to treat patients with a diagnosed tumour. Sub-concepts of Clinical_Intervention include therapy which in turn has Chemo_Therapy and Radio_Therapy as sub-concepts, Adjuvant_Method that might aid tumour treatment and Surgical_Removal as the surgical removal of cancerous tissue.

• • Medical_Agent is an umbrella term for substances used in examination and treatment. For instance, in Hadom, the treatment of brain tumour requires Anaesthetic_Agent, Anti_Convulsant and steroid that are sub-concepts of Medical_Agent; the MR imaging model might require an injection of contrast enhancing substances. The medical/biochemical agent used in a particular treatment will be introduced as instances of Medical_Agent or one of its sub-concepts, with names and the administered dosage documented.

• • Medical_Control is the parent concept of all the medical investigation modules including Biopsy, HRMAS, Magnetic_Resonance and Microarray. Among such different modules, Magnetic_Resonance has child concepts MRI and MRS and Biopsy has child concept Stereotactic_Biopsy.

• • Medical_Control_Outcome records all the information produced by and interpreted from a Medical_Control module.

• • Region_Of_Interest is a non-clinical concept. It is the area in or related to a patient's CNS that arouses clinician's concerns. It is normally instantiated as a mass, enhancement, or highlighted area in medical images or as a tissue to be examined ex vivo.

• • CNS_Anatomic_Structure describes the major organs and parts of organs related to the human brain. We use separate concepts for the functional aspect (e.g. Brain_Stem) of a particular organ and its structural aspect (e.g. Brain_Stem_Structure). A few properties are introduced to describe the spatial relationships, e.g. spatial_connected_to and spatial_within.

• • Diagnosis refers to terms in WHO CNS Tumour classification. An instance of Diagnosis is reported in a Patient_Record and is associated with a particular instance of Region_Of_Interest as an instantiated relation of the anatomical structure in the ontology.

• • CNS_Tumours is the WHO classification of Tumours affecting CNS. The hierarchical structure of the WHO classification is faithfully re-constructed in Hadom. Further extension and modification will be made compliant with WHO classifications. Indeed, we have both the 2002 and 2007 classification indices in the ontology.

The above categories are the top level concepts that are defined as the direct sub-concepts of the root concept, (e.g. 〈owl:Thing〉). Note that several categories are introduced in order to accommodate legacy terms and concepts from existing DBs schema, such as the INTERPRET DB (Figure 4).

Figure 4

Medical_Control, Medical_Control_Outcome and the actual data files

2.2.1 Patient record

Instances of patient record should be regarded as the point of reference of a system that uses Hadom (as shown in Figure 5). Normally, when a new patient P is admitted or reported, a new instance of Patient_Record is created, which includes a reference to an instance of the Patient concept to record the personal information of P. Instances of Symptom are created to describe the complaints of P. Instances of Medical_Control are introduced including those of different imaging modules so as to document information regarding the individual examinations that P has undertaken. Instances of Diagnosis are used to note down diagnostic details, while instances of Clinical_Intervention serve to keep track of treatments and surgeries.

Figure 5

Medical_Control, Medical_Control_Outcome and their sub-concepts

In order to retrieve the information of a particular patient, instances of Patient_Record again serves as the main entry point. For instance, assume that one wants to find all the patients who have an astrocytic tumour. He/she ‘glues’ instances of different concepts together using a Patient_Record instance as in the following query.

SELECT ?patient WHERE

(?pr, hadv:record_of, ?patient) AND

(?pr, hadv:diagnosis, ?diag) AND

(?diag, hadv:is_who_class, ?tumour) AND

(?tumour, rdf:type, Astrocytic_Tumour)

If a particular visit of patient P is identified by the URI x, the clinical history of P is accessed using the following pseudo-RDQL query.

SELECT ?patient_record WHERE

(?patient_record, hadv:record_of, ?x)

2.3 Medical control and relevant concepts

A number of technologies are used in brain tumour diagnosis. In Hadom, we enumerate four approaches, namely Biopsy, HRMAS, Magnetic_Resonance and Microarray. We defined them as sub-concepts of Medical_Control with properties that link necessary information, e.g. has_date property keeps a time-stamp on every medical examination.

Among the four approaches, Magnetic_Resonance is the main research focus of HA project. It has MRI and MRS as sub-concepts.

A medical control instance produces outcomes that are defined as Medical_Control_Outcome including Medical_Image, Textual_Report and data concepts for each of the different test modules (see Figure 4). Medical_Image covers the results of high throughput MRS and MRI. In practice, MRI outputs a stack of images taken at fixed intervals. This is reflected in the ontology as MRI_Image connecting to MRI_Image_Sequence through part–whole relationship. Textual_Report refers to a paper or the electronic reports generated by clinicians. It might contain the conclusions and descriptions of a set of images taken with respect to a particular patient.

The actual MR data might be in two forms: processed data and raw data. In order to trace diagnosis, it is necessary to have both forms of data available and linkable from a particular patient record. The actual data file and relevant information are kept as instances of MR_Data:

MR_Data = … ⊓ ∀ has_description.String ⊓ ∀ has_file_name.String ⊓

∀ has_creation_date.String ⊓ ∀ has_creation_id.String ⊓ …

3.1 Modularising HealthAgent domain ontology

Many of the technologies and methods used to detect and diagnose brain tumours are yet to reach a mature stage. This is made explicit by the fact that in 2007, halfway through the HA project, WHO released a new classification of tumours affecting the CNS with major changes to the terminology as well as to the taxonomies (http://www.who.int/en/). In light of further changes being highly likely, we have revised Hadom into a modular structure that confines changes locally to a module. Hadom has a core kernel containing the essential concepts from the domain and the top-level conceptual relations between these concepts, and the five modules below:

• • haMedCrtl.owl extends the core with concepts detailing the various medical examination methods, the results generated, and the materials used in such examinations.

• • haClassifier.owl enhances the core with knowledge prescribing how the input and output of automated classification methods should be constrained in the HA framework.

• • haSecurity.owl introduces a layer of system security-specific concepts and properties. When designing a health care system, one needs to not only accommodate the needs for clinical use but also observe patient privacy and safety issues, especially in a distributed environment, as envisaged by the HA network. Reflected in Hadom is a dedicated module for security concerns. We exercise a policy rule based security model regulating the access rights of HA users. Basic concepts to facilitate such an approach are:

  • – Access_Right regulating who can manipulate the data and how;

  • – User which is further divided into Software Agent, Clinician, Patient, and System_Admin;

  • – Resource as the data and methods available to users of the HA system.

• • CNS_Anatomic_Structure.owl details the anatomic structure of the human brain and CNS.

• • CNS_Tumour.owl gathers tumour types with or without histopathology results. Paediatric_Non_Histo is the parent concept for tumours. This concept is not necessarily required under histopathological studies. Yet, the WHO 2002 classification and the WHO 2007 classification co-exist under CNS_Tumour_Histopathology. With the help of clinical experts, we mapped the 2007 classification against the 2002 one and marked tumour types from 2007 with deletion, creation, split, merge, generalization, and specialization, similar to the types of changes proposed in (Noy & Musen, Reference Noy and Musen2004). With such a markup, we can establish correspondences between different WHO classifications and easily ‘revive’ legacy patient records dating back to 1950sFootnote 10. Note that a change between the two classifications may lead to marking a concept with different actions. For instance, the revision of Choroid_Plexus_Carcinoma suggests the creation of ‘Neuroepithelial tissue tumours’ in 2007, deletion of ‘Choroid plexus tumours’ in 2002, specialization of ‘Choroid plexus tumours’ under ‘Neuroepithelial tissue tumours’ in 2007 and deletion/creation of all the sub-type of ‘Choroid plexus tumours’ including ‘Choroid plexus carcinoma’.

  Moreover, we refine tumour types with tumour grading systems. Two different grading schemata are introduced in Hadom: the Dauma Duport grading system and the WHO grade as instances of the Dauma_Duport_Grade and the WHO_CNS_Tumour_Grade respectively, who are in turn sub-concepts of CNS_Tumour_Grading.

3.2 Modelling the anatomical structure of central nervous system

Representing anatomic knowledge has been studied extensively and many different approaches have been proposed, including the comprehensive foundational model of anatomy (FMA; Rosse & Mejino, Reference Rosse and Mejino2003) for humans. In Hadom, anatomical knowledge is used to establish the connection between diseases and human organs and we only focus on anatomical knowledge of the CNS. When constructing an ontology, establishing connections with existing ontologies such as FMA is recommended so as to maintain consistency with respect to the latest advances in the domain of discourse. This is not strictly applicable in Hadom for the following reasons. In order to connect diseases and human organs, part–whole relationships are necessary to infer potential damage to other neighbouring areas and to the neural functions that the entire region of the brain presents, of which the tissues under consideration are only a part. FMA uses a separate spatial ontology and models the partonomy information in the Anatomical Structural Abstraction Model. Specialist reasoning systems other than a DL-based one are needed; this makes the implementation unnecessarily complicated.

Using Damasio's study (Reference Damasio1995) as a reference, we sought a balance between a knowledge model containing an exhaustive and refined coverage of human CNS and a parsimonious construction that is sufficient for the HA framework. The fine line between domain and application ontology is identified with the help of clinical experts working closely with the HA development team. The criteria for opting to place a part of CNS in or out of the anatomical model is whether it is mentioned in the patient's EHR, whether its neighbouring parts are referred to in the patient's EHR, and whether its sub-parts are used in the patient's EHR. Using T _EHR as the set of anatomical terms that appear in patient EHRs, this choice criterion is formalized as:

We refine adjacent (x, y) to be spatially left_to, right_to, beneath, above, connected_to, inner, outer, restriction_surround, etc. A brain tumour might damage brain tissue that inevitably affects the corresponding neurological functions. In Hadom, a series of neurological functions are defined as instances of concept Nerve_Function and are associated with the brain's anatomical structure using property has_function. By doing so, one is then able to infer potential damage to normal muscle movements and senses based on the location of the brain tumour and other tumours of the CNS, and thus cross-check with a patient's observed symptoms.

In Hadom, we adopt the approach to modelling part–whole relationships in (Hahn et al., Reference Hahn, Schulz and Romacker1999) using only the subsumption relationship is-a inherent in DLs. Partonomy is emulated with is-a hierarchies of concepts introduced particularly for representing structural knowledge. CNS is viewed as a series of three coexisting concepts: the structural concepts that normally end with ‘_Str’, the anatomical concepts themselves and the part concepts that normally are with suffix ‘_Prt’. For instance, brain stem is defined by the combination of Brain_Stem_Str, Brain_Stem and Brain_Stem_Prt with two subsumption relationships ( i.e. Brain_Stem ⊑ Brain_Stem_Str and Brain_Stem_Prt ⊑ Brain_Stem_Str). Among the triadic combination, Brain_Stem is the one holding all the taxonomical knowledge while Brain_Stem_Str and Brain_Stem_Prt are the bridge to establish the partonomical chain of anatomical structures.

On the basis of this triadic combination, the left cerebral hemisphere is defined as

Left_Cerebral_Hemisphere ⊑ Left_Cerebral_Hemisphere_Str ⊓ …

Left_Cerebral_Hemisphere_Prt ⊑ Left_Cerebral_Hemisphere_Str

Left_Cerebral_Hemisphere_Str ⊑ Cerebrum_Prt

Cerebrum_Prt ⊑ Cerebrum_Str

Hence, if a tumour is identified within Left_Cerebral_Hemisphere, we can safely infer along the partonomical chain that it is also within Cerebrum structure and thus is part of Main_Brain structure. For simplicity, we define knowledge of anatomical structures at ‘xxx_Str’ and use the anatomical concepts to usher in references to conventional anatomy terminology.

3.3 DICOM'ising HealthAgent domain ontology

The Digital Imaging and Communications in Medicine (DICOM)Footnote 11 standard was initiated by the American National Electrical Manufacturers AssociationFootnote 12 to regulate the distribution and viewing of medical images, and later become a global standard adopted by clinical authorities and manufacturers from major European and North America countries. DICOM has become an increasingly common format for receiving scans from hospitals. Therefore, even though DICOM descriptors are closely tied to implementation details, that is, how image files are composed, stored, transferred, etc. rather than at the conceptual structure of the domain of discourse, we enrich Hadom with a DICOM reference module to enable smooth migration to a DICOM compatible system.

Among DICOM standards, the Image Information Object Definitions (IOD) impinge on Hadom. IOD impose a standard format when transferring medical images. Depending on the purposes of medical studies and the nature of associated data, IOD differentiate Patient Module for patient data, Series Module for information related to particular imaging modules, Study Module for information about the entire medical study, etc. Correspondences are manually crafted to facilitate the inspection of Hadom concepts in a DICOM apparatus. More specifically, Patient Module in DICOM perfectly matches the Patient concept from Hadom with nearly one-to-one correspondence between DICOM and Hadom properties. Study Module is translated into Patient_Record in that Hadom's patient records comprise all the information concerning a patient on a particular disease from the first visit that he/she made to one of HA member hospitals until the end of his/her treatment. Series Module stays one level below Study Module and is mapped to Case_Record including information of a particular visit of a patient. Image Module details how images are taken. Depending on the image types, Image Information is saved in respective sub-concepts of Medical_Control and Medical_Control_Outcome.

4.1 Communicating with HealthAgent domain ontology

Hadom is used as the common reference point among different clinical centres/hospitals that maintain their own vocabularies and DB schemata. As illustrated in Figure 7, such a design seeks to respect the integrity and independence of legacy DBs. The discrepancy between such schemata is, however, resolved by dedicated interfaces between each individual schema and the common domain ontology Hadom.

Figure 7

HealthAgent domain ontology to facilitate inter-agent communications

A typical scenario of using Hadom starts with the visualization of a particular patient record read from the local DB. The visualization is controlled by the ontology. Information read from a local DB is translated into a format compliant with Hadom via a relational DB to an RDF interface to create instances of Hadom. Such instances are then classified and displayed in the allocated sections in the HA GUI.

Agents of different types are equipped with parsers understanding Hadom that ensure Hadom -compliant communication between them (see Figure 7). For instance, when querying a classifier, the handling agent would submit queries composed using terms drawn from Hadom. For instance, the RDQL query illustrated in Figure 6 retrieves all the patients that are diagnosed by the Birmingham Children Hospital (BCH).

4.1.3 The HealthAgent OntoDB mapping toolkit

The HA mapping toolkit is a software application that has been developed for mapping between an HA legacy DB and the Hadom. Motivated by the idea of automating the mapping process between an ontology (concepts and properties) and a relational DB schema, we designed the toolkit with a ‘drag-and-drop’ feature to facilitate ease of use. This toolkit allows the user to relate concepts in a given ontology to entities present within a relational DB with the final goal of obtaining a mapping script, using the D2RQ language for its representation.

The D2RQ framework contains a mapping language for treating non-RDF relational DBs as virtual RDF graphs, and a platform that enables applications to access these graphs through Jena and Sesame APIs, as well as over the Web via the Sparql protocol. The full specification of D2RQ language as well as its platform are available from http://www4.wiwiss.fu-berlin.de/bizer/d2rq/spec/. The generated mapping scripts allow any given user, who does not need to know the organizational schema of a DB, to query the DB via the Sparql language powered by an ontology.

In the following, we present the functionality of the toolkit and its usage in a practical setting. This allows us to illustrate the approach taken for its design, and also conveys the full extent of its capabilities. In doing this, we start by roughly describing a typical workflow of a user working with the application. A user is presented with the option of loading an OWL ontology visualized through the built-in interface. At the same time, the user can load a relational DB schema specified either by an XML file or by access to the location of the actual DB server. The DB schema is visually available through the interface provided by the application. Once the ontology specification and the DB schema are loaded, the workflow execution begins by presenting the user with a directed graph that shows the entities (nodes) within the DB and the relationships (e.g. foreign keys) among them. Apart from this, a series of windows appear which are used to specify the concepts and entities to be associated by dragging graphical renderings of related items and dropping them into a common space to articulate their association. Figure 8 shows a screenshot of the application with an ontology and a DB loaded. At the centre of the window, the graph representing the DB schema is displayed.

Figure 8

Graphical user interface of the HealthAgent mapping toolkit

In order to improve usability, the workspace of the mapping toolkit is divided into four different areas used to present the different types of information involved in the mapping process:

• • The ontology area shows, in two windows, the concepts available within the ontology and the properties of the currently selected concept (marked 1 in Figure 8);

• • The visualization area, apart from the graph mentioned above, presents two further tabs: one displaying the D2RQ file being generated by the mapping process and the other, a table presenting the data available on the DB for the selected entities over the schema (marked 2 in Figure 8);

• • The DB area shows the schema of the specified DB (tables and their fields); it also makes available a window with suggestions of DB schema tables as the mapping candidates of the currently selected ontology concept (marked 3 in Figure 8);

• • The mapping area displays the D2RQ specifications and the way of presenting the information on the mapping. In this space, all the D2RQ specifications can be filled in to obtain a complete mapping description. This area also fosters two sub-spaces: one on the side of the ontology (ontological concepts and properties) and the other on the side of the DB (DB tables and fields, that are being related within the current mapping description) (marked 4 in Figure 8).

Given the intuitive character of the application's interface, the only thing to be done in order to relate a concept in the ontology (or any of its attributes) to an entity within the DB is to select the desired object, drag it to the correct window within the mapping area and do the same for the corresponding entities in the DB. Figure 8 shows how easily the mapping process is carried out, with a few concepts already mapped and an ontology concept being dragged to the mapping area to relate it with its counterpart within the DB.

In order to complete the mapping script the user must repeat the drag-and-drop action for each concept from the ontology that needs to be mapped. At any time during the development of the mapping, the user is allowed to visualize the current mapping script file. Another useful functionality is the possibility of querying the DB, at any time, using the tab window provided for that specific purpose. In doing this we illustrate a statement, articulated in the introduction, that an ontology provides a conceptual integration of the range of questions one would expect to have answered about a domain. As such, the meanings of terms get explicated with reference to the answers obtained from queries that involve these concepts. This helps the user to decide, based on the information stored in the DB, to which concepts and given entities from the database schema are related. At the end of the mapping process the user has, within a mapping script file, all the mapped concepts and the correspondence with the original database entities for direct editing (Figure 9 shows an example of the mapping script file).

Figure 9

D2RQ file containing the mapping description

4.1.4 Accessing data functionality

The mapping of a database into Hadom is performed by the DB Agent using the mapping script containing correspondences between the DB schema and the ontology. The DB Agent is also responsible for checking permissions before the secure delivery of the requested information. This process is made through the validation of the user who sends the Sparql petition to the DB Agent via a GUI Agent. Each user has a unique ID that is obtained and maintained by the GUI Agent and attached to all the messages containing Sparql queries sent to the DB Agent. If the user has enough privileges to see the medical cases retrieved by the DB Agent of a particular clinical centre, and the requested cases are marked as public then the results are passed to the GUI Agent who shows them to the user. Figure 10 illustrates the described flow of information between an HA client node and all the other client nodes in the network. Further details of the security arrangements are provided in a companion paper in this issue.

Figure 10

Information flow between a client node and the HealthAgent network when retrieving medical cases

Each HA node owner of a DB with information to share must also have its own DB Agent with the corresponding mapping file. Nevertheless, any HA node can also join the HA network even if the node does not have its own DB (the dotted components within the client node are optional as is shown in Figure 10) but may want to retrieve information from the DBs of other medical institutions.

In order to execute the HA DSS at a clinical node, the HA framework needs to be running and the Data Collector Agent invoked. If this initial requirement is satisfied, the DSS can be started and the first screen is used by the user to log on the system (Figure 11).

Figure 11

Login screen of the HealthAgent decision support system

During the log on process, the user is authenticated according to his/her security permissions and if the user name and password are correctly registered, then the GUI Agent is started. The first task of the GUI Agent is to know whether the node of the user has its own DB Agent. If a DB Agent exists, then the GUI Agent builds a Sparql query to get some fields that are presented on the next screen. This information contains data such as the possible values for the age, gender of the patients, all the values for the patients’ geographical origin and tumour locations. The values retrieved are used to fill the combo boxes that the user can manipulate to define a search criterion for a patient's case notes (see the search neurooncological cases screen in Figure 12).

Figure 12

HealthAgent decision support system screen for search neuro-oncological cases

The next screen after the authentication is where the user can request the neurooncological records from his/her own DB (if it exists) or from all the available external clinical centres. As previously stated, in this screen the user can define the search criteria to filter all the medical data available on the HA network. These parameters include specific information about the patient such as the gender, the range of age, the geographical origin or the tumour location (if it is already available). Once the user has set the parameters for a search, the GUI Agent builds the corresponding Sparql sentence that is sent to the Data Collector Agent who distributes the query and collects all the results retrieved from all DB Agents. After the GUI Agent receives the collected data, it presents the neurooncological records obtained to the user. The cases shown in Figure 12 were obtained in a pilot study using three distributed clinical nodes, two of them with a different DB schema and running with different DB engines (MySQL and Oracle version 10). The neurooncological records listed in the results were obtained from two of the three nodes (those with different DB schemata and engines) while the results of the third clinical node were hidden given the lack of user's permissions.

5.1 Subsumption, instance classification and other ontological reasoning

Hadom provides a controlled vocabulary for the use of classifiers and the construction of GUIs. For instance, depending on the requirements of the user, whether she is a radiologist or surgeon or oncologist, Hadom provides a well-structured model to simplify the development of an adaptable user interface. Similarly, while HA classifiers take data from the data providers and generate classification labels using pattern recognition methods, Hadom is used to regulate the input and output labels for the classifiers by offering a controlled vocabulary as a uniform communication interface. Classifiers are developed at different centres using different data sets and with the goal of resolving different questions. Therefore, for instance, there may be classifiers developed to distinguish between low-grade meningiomas and aggressive tumours, including high-grade glioblastomas. The terminology belongs to the set of terms sanctioned by the WHO classification, and these classification labels reflect their actual usage among clinical practitioners. However, from a knowledge engineering viewpoint, such a mixing of the attributes of tumours (aggressive, or grade, or whether they have undergone metastasis) and their principal conceptual identity (glial tumours) has to be disentangled to create the conceptual hierarchical structure. If not, idiosyncratic usage in different clinical centres would impede the job of coordinating the outputs of classifiers developed in one centre but deployed elsewhere in the HA network for software agents. Using the capabilities of logical reasoning offered by OWL, the identification of clusters of concepts used across the HA network in diagnosis offers potential future benefits for medical advances in this domain.

In this context, reasoning is defined as making explicit statements that are implicitly encoded in the representation. In the following, we will present the reasoning capabilities of Hadom. Generally speaking the reasoning mechanisms supported by Hadom relate to subsumption. More precisely, the ontology allows for one to infer out of (i) ‘A is a sub-class of B’ and (ii) ‘x is a member of A and B’. If, for example, ‘Glioblastoma Multiforme’ is considered as a sub-class of ‘Astrocytoma’ and an unknown mass is classified as ‘Glioblastoma Multiforme’ based on its appearance and biochemical characteristics, then we can automatically infer that this unknown mass is an astrocytoma. Another reasoning pattern is the inheritance of properties along the conceptual hierarchy. An ontology allows one to infer from (i) ‘A is a sub-class of B’ and (ii) ‘B has property P’ that ‘A has property P’. In the previous example, this unknown mass bears all the features defined for an astrocytoma and will automatically inherit the necessary constraints defined directly for astrocytoma. Defaults and exceptions might be applicable in this case when complete domain knowledge is not available, but these specifications are not encoded directly in the ontology as elements to perform reasoning with, but only as properties to retrieve information about. Building upon the above mentioned mechanism we can also utilize reasoning to ensure the correctness of the knowledge acquisition process. If, for example, it is known that a patient is characterised by three properties: age, sex and location and a DB query only retrieved two of such fields, then the missing information is flagged up and a notification of the appropriate action provided.

5.2 Better information accessibility

Hadom underpins the HA evidence-based search system (EbSS; Matthews, Reference Matthews2008) for well-targeted information extraction from online literature and patient DBs. In evidence-based medicine (EBM), pieces of evidence from various scientific studies are evaluated and applied to ensure that the best outcomes can be expected based on the current status of knowledge. Hence, in EBM, identifying and retrieving the appropriate information is critical. In many cases, such information is not readily available and the clinicians and other information requestors are overwhelmed by the large number of publications from online repositories such as PubMedFootnote 14, emedicine,Footnote 15 etc. Finding useful information from such sources could be time consuming and inefficient. Classifying clinical research against a domain ontology imposes a schematic view over the information sources that helps the requestors to quickly zoom in and identify the most relevant information. For instance, when searching for diagnosis and prognosis information with respect to Choroid Plexus Carcinoma, Hadom allows one to extend queries not only to the parent concepts of this particular type of brain tumour but also to the new tumour type defined in the WHO 2007 classification by means of the links/properties among Hadom concepts. Similar systems based on general ontologies have been successfully commercialized (cf. GoPubMedFootnote 16). HA EbSS, different from such general purpose information portals, takes advantage of Hadom in generating queries and filtering search results that are specifically tuned against HA domains.

Rendering information in a meaningful way also has implications for how well information is conveyed and apprehended (Herman et al., Reference Herman, Melançon and Marshall2000). In the HA system, information is collected from different sources and is displayed based on the nature of the request and the identity of users. This lays down two requirements on the HA user interface, namely integrating and role-based information provision. When implementing the HA system, the integrating requirement is facilitated by annotating clinical data using concepts from Hadom and projecting it onto patients’ EHRs in a chronological manner. From EHR, therefore, users can navigate to the clinical history of a patient, the various clinical investigations performed on him/her, etc. It is also possible to retrieve the relevant clinical research literature displayed alongside patient's EHR via the HA EbSS. The HA system also practices a strict information filtering process based on the roles of users. Currently, Hadom defines a list of roles that can be played by a human user or a software agent. Associated with each role are its rights and authorization that are used to annotate fragments of patient data. When browsing and navigating through a patient's EHR, one is presented with the data that he or she has clearance for and is prohibited from viewing or modifying those for which he or she has not been granted access rights.

6.1 System functionality

The HA system is effectively running with data nodes residing in both Spain (i.e. Universitat Autónoma de Barcelona (UAB) and Universitat de Valéncia (UV)) and the United Kingdom (i.e. BCH). Each data provider is allowed to maintain the integrity of their legacy data to avoid disruption to existing tools and systems. In the meantime, the heterogeneity inherent in the independently collected data is tackled by means of Hadom. Although further evaluation of the HA system is necessary, usability and reliability studies of the current release of the system have confirmed that:

• • Hadom is sufficiently expressive to cover the legacy data from all participating hospitals and clinical centres. Data have been faithfully converted and no knowledge loss has been reported.

• • Hadom is capable of representing inputs and outputs of classifiers and other data processing agents. Hadom serves as the unified language to ensure service and data interoperability within HA .

• • Modularized Hadom enhances the extensibility of the HA system and enables specialist software agents. For instance, data anonymising agents can be developed against each imaging and clinical module with their outputs projected upon Hadom for alignment.

To summarize, Hadom successfully facilitates an unobtrusive mechanism for transferring heterogeneous data among different sites without requiring the active engagement of human users. Yet, a major disadvantage of Hadom has been revealed during the evaluation. The HA classifiers normally offer class labels together with numeric values to justify and contextualize the classification. Thus far, Hadom uses a URI to point to a data file holding such values (e.g. matrices) or treats them as strings using string type properties (e.g. hasParameter). While such approaches have been demonstrably successful in leveraging diagnostic classification tasks to be executed over the HA network, they offer access to the patterns in the data only through their algorithms and interfaces. This precludes any possibility of combining reasoning based on these numeric values directly with ontology based inferences. Although conceiving a new reasoning algorithm with concrete datatype is beyond the scope of the HA project, research on integrating logic based knowledge representation formalisms with uncertainty is relevant to this task (cf. Costa, Reference Costa2005; Lukasiewicz, Reference Lukasiewicz2008).

6.2 Clinical terminology

The diversity of the HA consortium offers a good test bed for Hadom. The first version of Hadom was mainly based on published literatures, interviewing various domain experts from UAB and observing the daily work of selected domain experts with the think-aloud protocol (Wright & Monk, Reference Wright and Monk1990). This draft version was then reviewed by domain experts (potential HA users and clinical consultants) from UV and BCH in three consecutive steps. First, the domain experts were given a pre-interview so as to build up essential knowledge on Hadom and to introduce them to the idioms of knowledge representation languages (namely DL constructs). They then walked through the ontology with or without the help of knowledge engineers. A post-interview was performed against a questionnaire to collect their questions, comments and observations. This variant of the usability evaluation method (Rubin, Reference Rubin1994) is based on practical considerations—the limited availability of clinicians prevents a prolonged interview and thus a guided one could ensure that necessary feedback was duly gathered. Expert feedback was used to revise Hadom.

Moreover, Hadom revision was reviewed against the eTUMOUR data model. One of eTUMOUR's objectives was to collect real patient data for establishing effective clinical decision support methods. The eTUMOUR consortium overlaps with the HA consortium and was expected to share a large amount of data with HA. Therefore, Hadom should be compatible with the DB schemata from eTUMOUR. One of the consequences is that Hadom ‘s naming and modelling conventions have to accommodate the design considerations in eTUMOUR. Such a link was made through the development team in MicroArt that was responsible for DB design in both projects.

Finally, Hadom was further evaluated through manually constructing mappings between the domain ontology and legacy DB schema by domain experts. A major assumption behind such an approach is that one can safely conclude that Hadom satisfies the applicability and usability requirements if a domain expert with limited knowledge on ontology engineering could establish the mappings correctly. Two experts from BCH responsible for handling patient data were summoned for the study. With guidance from knowledge engineers, mapping was successfully constructed. Feedback from the two domain experts led to further changes on Hadom including new names and conceptual structures.

6.3 Facilitating translation

The last phase in evaluating Hadom was done with the help of the graphical mapping toolkit. Thus far, many mapping tools are available to suggest candidates between ontologies and DB schemata (see for instance the survey by Rahm & Bernstein, Reference Rahm and Bernstein2001). A strong argument against adopting such automatic mapping methods in HA is that although labelled with ‘semantics’, most approaches fail to inspect semantics in terms of cognitive expectations that emanate from working within established working practices within institutions. In addition, these cognitive biases are shaped within different perspectives and implicit conceptual models rooted in the users’ educational, cultural and societal background (Fodor, Reference Fodor2004). It is unrealistic to expect effective automation for ironing out these potentially distinct conceptions, raising the need for accommodating these discrepancies when constructing mappings. The situation is aggravated when mapping Hadom against legacy DB schemata due to the fact that we have to observe the integrity, specificity and historically acquired idiosyncrasies of the latter.

Furthermore, in practice, we found the following difficulties prevented us from adopting automated mapping tools. First, the diversity of the legacy DB schemata made automated approaches less feasible. There were cases that one Hadom concept was mapped to more than one DB table combined through a series of join operations; one Hadom concept was mapped to a number of columns that did not have obvious relations one could rationally describe; one Hadom property was mapped to multiple table columns depending on whether or not it satisfied certain auxiliary conditions, etc. Second, many well-performed automated mapping tools rely on external data sources (e.g. WordNet; Miller, Reference Miller1995), reference ontologies or instance data. Such information was either not available from the legacy DBs due to patient privacy concerns or not applicable because of the existence of a large number of hospital specific abbreviations and acronyms. Using an automated mapping tool would require tuning against individual hospitals and would lead to prolonged validation phases. Third, even if an automated tool had been used, human involvement would have been inevitable due to strict patient safety requirements. The benefit of adopting such tools was not evident given the size of the problem—after modularization, each domain expert, with even a rudimentary understanding of the meanings of the entries of the DB schema, would not find it difficult to map and review mappings of about 30 concepts. The mapping toolkit, however, leverages basic string similarity metrics to recommend potential mapping candidates.

A preliminary usability study of the graphical mapping tool was carried out. Four people with different computing skills and different backgrounds were selected. They were presented with the Hadom ontology and one of the real-life legacy DB schemata and were asked to map a few preselected concepts. The feedback on the user interface and the automated generated D2RQ script was positive, suggesting that the layout was intuitive and significantly reduced typos and human errors. Negative comments include the confusing visualization of the ontology, the difficulty of navigating through different tabs and windows and the lack of ‘intelligence’ in recommendations—recommendations are mainly based on name matching. We expect to continue the development of the graphical mapping toolkit and perform formal usability and design studies beyond the HA project.

6.4 Concluding remarks

In conclusion, this paper presents our efforts towards building an ontology for HA. Our main motivation behind the work was driven by a desire to provide a declarative framework to separate the functionality of the system from an articulated interface derived from user requirements that were informed by frequent meetings for validation with the clinical partners. We have shown how we implemented the ontology, as well as the mechanisms for accessing the data using the ontology by domain-specific examples. The main contribution of the paper is twofold. On one hand, we show a ‘hands-on’ example of building an ontology in practice, and how making it work in distributed settings requires translations and intermediate placeholders in order to include legacy representations. This is especially important in an era where more and more information is acquired and annotated with metadata so that methods for their (semi) automatic informed manipulation become essential. On the other hand, we make explicit the implicit modelling choices when building an application ontology for a given domain. This has been an interesting process that could serve as a future reference point for similar work.