NeurOn: Modeling Ontology for Neurosurgery K. S. Raghavan & C. Sajana Indian Statistical Institute Bangalore

Information & Healthcare Health care is a knowledge intensive activity; Available knowledge is a fluid mix of: Scholarly documents New experiences Contextual information Expert insights collectively providing a framework for decision-making

Information & Healthcare Patient records as an important source of valuable information Much of this valuable information may not even appear in published sources or become a part of standard texts until years later Quality of health care vis-à-vis access to patient records with defined similarities to the problem on hand

K. S. Raghavan, Indian Statistical Institute, Bangalore, India Decision-making is… something which concerns all of us, both as makers of the choice and as sufferers of the consequences. -D. Lindley K. S. Raghavan, Indian Statistical Institute, Bangalore, India

Background The work reported here is set in a large hospital (and is in progress) Present system & its limitations WINISIS database with hyperlinks to related files (Such as X-rays, CT Scans, Pathology reports, etc) Data on a large number of parameters The range of relations between concepts in a complex domain such as health care Search technologies in thesauri – based IR systems

The Present Study Hypotheses Why Ontology? Ontologies can help build more effective information support systems in healthcare. Ontologies can support the need of the healthcare and delivery process to transmit, re-use and share patient data Why Ontology? Ontologies are effective in representing domain knowledge Possible to include ‘IF – THEN’ rules to support inferencing

Ontology? Gruber’s Definition: “Explicit Specification of a Conceptualization” Studer’s extension: “ a formal, explicit specification of a shared conceptualization” For practical purposes and applications a domain ontology could be perceived as: The complete set of domain concepts and their interrelationships

Ontology? A semantic network of concepts grouped into classes and subclasses and linked by means of a well defined set of relations. Ontologies also have a set of rules that support inferencing

The Project About 1500 patient records of the Neurosurgery unit of a large hospital The neurological disorder disease name (Final Diagnosis) specific treatment symptoms associated illnesses Patient Data; name, ID number, doctor’s name, disease index number, gender, age, age range, consciousness level, visual acuity details , etc

Neurological Disorder The central theme of every patient record ran more or less like this: A Patient Neurological Disorder that is Has Diagnosed and Treated Method of Treatment Using Result Leading to

Domain Concepts Patient Records contained four broad types of data: These could be categorized under the 3 top level categories of Ranganathan, viz., Personality [P], Matter Property [MP] and Energy [E] Medicine-Related Concepts Patient-Related data Healthcare Personnel Related data Institution-Related data

Queries In building the ontology it was important to have some idea of the nature of queries that the system should respond to: Identify Patients above 40 years of age and suffering from Astrocytoma Patients with brain diseases having symptoms of headache and visual impairment Records of patients who were administered drug XXX and had post – surgery complication of vision loss

Queries While a clear picture will emerge only after the system is implemented; A small query library was built to serve as the basis for defining classes and sub-classes

The Ontology No one perfect way of building an ontology Definition of classes, properties, etc. decisions regarding how detailed the classes and / or relations should be is largely based on the purpose and ease of maintenance ’female patients’ could be seen as a subclass of ‘patients’; it could also be handled as: Patient HAS GENDER and by fdefining acceptable values for gender

The Ontology The decision-support system proposed here is conceived to have at least two major components when completed: The ontology as part of the search interface; and A database of patient records linked to related records in other databases, e.g. of images (scans, X-rays, etc)

Populating the Ontology Phase 1 Medicine-related concepts - neurological disorders including associated symptoms and characteristics and their treatment – patient data. Other sub-domain concepts will be added later Complex nature of relations

Populating the Ontology Structuring the terms into a hierarchy Inconsistencies in terminology used by hospital’s health-care personnel SNOMED CT was used to standardize the terminology Corresponding MeSH Terms & terms used by hospital personnel built in as relations: [SNOMED CT for Domain Concept] <has physician’s term> [Term used in the patient record]

Populating the Ontology Properties Object Data type A general idea of the class hierarchy and properties (see Figure)

Future work To be implemented in the hospital Only a limited number of patient records used Tested with a few sample queries To include concepts related to healthcare institutions and personnel To link relevant manuals, reference sources, text books and papers with a view to widen the knowledge base available to the users of the decision support system

Future work To build rules for inferencing that allow reasonable and intelligent guess of the probable cause or condition of a patient based on values of certain clinical parameters decision regarding the possible course of action defining parameters that could generate an alert message

Future work The complexity of medical terminology; Non-availability of exact equivalents for some of the terms used (in patient records) in the standard medical terminologies (like MeSH and SNOMED CT) Ethical issues Can we define principles for decisions regarding ‘classes’ ‘subclasses’ ‘properties’ and ‘relation types’ for ontology?