Introduction

The sense of sight is the most important gift of human creation, allowing us to experience the whole range of life, from brilliant colors to nuanced expressions. Vision loss can negatively affect quality of life, leading to limited mobility, social isolation, and depression1. Regular eye exams are important for early detection and treatment of disorders such as glaucoma, which can prevent vision loss in up to 95% of cases2. Furthermore, ocular examinations can identify systemic disorders such as diabetes and hypertension3. Prioritizing eye health is crucial for general well-being and quality of life4.

In today’s healthcare information systems, there is a growing demand for technologies that allow formal knowledge representation. Semantic Web technologies and ontologies offer powerful solutions for representing, integrating, and retrieving data. By providing shared, machine-readable concepts, ontologies are essential for achieving interoperability across systems and organizations5. In healthcare, particularly ophthalmology, ontologies structure domain knowledge into meaningful entities, relationships, and axioms6. They improve data accuracy, support clinical decision-making, and facilitate seamless communication across systems and languages by making information more accessible and well-organized7.

In ophthalmology and healthcare informatics, organizing and representing knowledge on common eye diseases remains a significant challenge. A comprehensive, standardized ontology that covers the full spectrum of eye diseases, their subtypes, symptoms, diagnostics, and treatments is still lacking. This gap limits the availability of a foundational resource for ophthalmologists, researchers, healthcare professionals, and patients alike, hindering precise diagnosis, effective treatment planning, and research advancement. To address this, we developed the Eye Disease Ontology (EDO) to provide structured, organized knowledge in the field of ophthalmology.

However, existing research focuses narrowly on specific conditions, such as ocular inflammatory disorders or glaucoma. As a result, current ontologies lack the scope to effectively detect and classify common eye diseases and their subtypes, highlighting the need for a more comprehensive framework.

EDO, addresses this limitation, by creating this ontology, we can better understand the numerous variables that contribute to eye disease, resulting in a more precise and informed strategy to manage and prevent common eye diseases.

EDO is a comprehensive and systematic knowledge representation system that organize information about commonly occurring eye diseases. Each medical condition is classified and connected to imperative information such as symptoms, causes, risk factors, signs, diagnostic tests, and treatment options. The goal of EDO is to support knowledge sharing and interoperability by establishing a common language for sharing and integrating ocular health information in eye disease research and clinical practice. In ophthalmology, EDO is a broad framework for semantic representation and knowledge organization. We have validated EDO by incorporating a real-life use case of a patient having an eye disease. Furthermore, through the use of SPARQL queries, the EDO offers an efficient way of retrieving and extracting relevant information. Rest of the article is organized as, related ontologies and potential research gap is discussed in section 2, different designs and architectures of developing ontologies are explained in section 3, details of EDO is discussed in section 4 and section 5 and modules of EDO are explained along with the usecase in section 6. In section 7 we have discussed conclusion and future work.

Related work

Healthcare systems are rapidly evolving with the integration of web semantics and digital technologies. The development of medical ontologies plays a critical role in enhancing data integration, interoperability, and decision support in healthcare. They are essential for standardizing terminologies and enabling effective knowledge representation in diagnostics. These ontology-based decision support systems often serve as the foundational backbone of AI-based healthcare information systems. Several AI and deep learning strategies have been developed to improve ocular illness detection and diagnosis. Cheung et al.8. improved screening programs, whereas Felfeli et al.9. established AI’s predictive capability by employing electronic health records. Pur et al. used classification algorithms to investigate biofluid markers for corneal problems.

Banerjee et al.10. discussed the limitations of applying ML to tiny datasets in rare eye disorders, emphasizing the importance of detailed disease ontologies. Deep transfer learning (Wang, 2019) and VGG-16-based models (Li, 2019) have been created to diagnose retinal disorders. Bavaresco et al.11. developed an ontology-based framework for detecting occupational injuries that makes use of Vision-Based Deep Learning.

Multiple expert systems have been created, such as rule-based12, forward chaining13, certainty factor14, and Naïve Bayes-based models15. Juneja et al.’s AI system automates glaucoma detection, while image processing, IoT, and cloud computing are employed for early identification of disorders, including hypertensive retinopathy16.

Ontologies give a formal, organized representation of domain-specific information, which is critical for enabling interoperability in healthcare systems. In ophthalmology, several ontologies have been proposed to handle specific aspects of disease modeling and decision support. For example, Maarouf et al. created a glaucoma-specific ontology to standardize terminology in patient data17. Henninger et al. proposed a method for modeling ophthalmic knowledge, providing a conceptual understanding for both knowledge engineers and ophthalmologists18. Pendleton et al. presented an ontology for immune-mediated inflammatory disorders (IMIDs) of the eye, emphasizing patient-preferred words and data extraction from internet forums19. To facilitate surgical decision-making, Scherer et al. designed a cataract ontology, allowing semantic visualization for ophthalmic surgeons20. Another work, OntoPhaco, aimed to formalize knowledge for Virtual Reality (VR) training in cataract surgery21. Additionally, Groza et al. developed an ontology for age-related macular degeneration using structured input from domain experts22, while Sergouniotis et al. emphasized ontology use for rare ocular disease standardization and research data exchange7.

Most of the existing ontologies were developed using literature studies and semi-automated ontology engineering techniques. For instance, Tamjid et al. used a semi-automated text-mining technique to create a glaucoma ontology, which achieved considerable term coverage when compared to standard disease ontologies23. Some ontologies rely significantly on manual curation and expert feedback, which, while reliable, might limit scalability and completeness. Many existing models drew upon BioPortal ontologies and employed tools such as Protégé for ontology design, following OWL (Web Ontology Language) standards. Despite the utility of these methodologies, they often suffer from narrow scope, focusing on single diseases, and limited generalizability.

While these ontologies exhibit development, they have significant shortcomings, including a lack of comprehensiveness. Most existing ontologies focus on a specific disease (e.g., glaucoma, cataract) or use case, rather than providing a comprehensive model for various prevalent eye illnesses. Furthermore, scalability concerns arise from limited expert engagement during development, resulting in models that are neither scalable nor universally applicable. Several ontologies do not use standardized medical terminologies, resulting in interoperability concerns between systems and languages. Because of their restrictive design or rigid hierarchies, previous ontologies have not integrated clinical workflows. Although several recent studies have tried with language models (e.g., GPT-3), these approaches rely on high-quality structured input, which is still a barrier in medical literature mining.

The proposed EDO aims to address the aforementioned limitations by providing a comprehensive model for common eye diseases that includes a wide range of diagnostic and treatment-related concepts such as symptoms, medical history, risk factors, signs, treatment strategies, and follow-up protocols. To enable semantic compatibility, align with established terminology and ontological frameworks. Furthermore, the use of OWL standards and modular design principles allows for integration with healthcare information systems and AI pipelines. By increasing generalizability, the ontology can assist not only in representing existing diseases but also in accommodating new disorders and surgical techniques in ophthalmology. EDO thus addresses a significant gap in the semantic representation of ocular knowledge, particularly for routine clinical use, which has been overlooked in literature. It makes a substantial contribution to the emerging field of semantic healthcare technology by ensuring structured, scalable, and interoperable knowledge representation.

Design methodologies

Ontologies play an essential role in enabling the exchange and reuse of knowledge, while also offering a user-friendly and easily maintainable framework. The purpose of developing an ontology is to systematically represent and organize the information and ideas about a specific domain in a structured and computationally interpretable manner. There are various methodologies for the creation of ontologies, such as Methontology, On-To-Knowledge, Diligent, Neon, and more24. Methontology methodology, provides a rigorous and systematic framework for creating ontologies from scratch, with its emphasis on the conceptualization, specification, and implementation phases, enabling experts to develop strong and interoperable ontologies. The On-To-Knowledge methodology encompasses a strategy for analyzing a problem, gathering requirements, formulating a concept, writing a specification, implementing the idea, evaluating its effectiveness, and documenting the process. This permits the development of robust ontologies that can collect and represent knowledge within specific domains. Both Methontology and On-To-Knowledge are regarded as the most comprehensive approaches for creating single ontologies from scratch, but they do not allow for the reuse of ontological and non-ontological resources. According to the Diligent ontology generation process, it requires extensive subject knowledge, stakeholder interaction, and iterative refinement. This methodology ensures the creation of accurate and well-structured ontologies while aiming to develop distributed and collaborative ontology engineering. However, this method lacks guidelines for effectively utilizing both ontological and non-ontological resources during the development process, and it does not provide a clear sequence of activities for the ontology creation process. The NeOn methodology is a professional and collaborative method of working that puts a lot of emphasis on scalability and resource reuse. It employs an organized and iterative process that involves stakeholders and analyses the subject’s needs. It encompasses nine distinct scenarios about ontology engineering and development, each with a defined sequence of activities. This methodology enables the construction of robust ontologies capable of seamlessly integrating with diverse applications within the specified scenarios while prioritizing modularity and integration.

Development of eye disease ontology

Despite the diverse variety of proposed ontology development approaches and procedures, none, as far as we know, supports all of the new trends in ontology network development. These concepts encompass complicated scenarios requiring the reuse and reengineering of knowledge resources, including ontologies, non-ontological resources, and ontology design patterns, as well as the involvement of software developers and ontology practitioners. On this basis, we chose the NeOn approach framework, a scenario-based approach that gives precise details for constructing ontologies and ontology networks while also emphasizing knowledge resource reuse and reengineering. Unlike prior methodological approaches, this framework does not prescribe a complex technique but offers several processes and directions for carrying out various procedures and tasks. The framework’s nine flexible scenarios address common scenarios, such as when ontologies need to be reengineered, aligned, modularized, and localized to support different languages and cultures, as well as when they need to be integrated with both ontology design patterns and non-ontological resources such as classification schemes or thesauri. As we are reusing ontology resources, we chose scenario 3 (Reusing ontological resources) of the NeOn methodology.

A stepwise flow outlining the application of NeOn in the creation of the Eye Disease Ontology (EDO) is provided below to enhance clarity, reproducibility, and transparency of the development process.

Ontology search

Ontology developers can utilize a variety of ontological resources found in ontology repositories while creating new ontologies. They can be used in a variety of ways, like it might be the complete thing, a section of it, or a module. This occurs when relevant resources exist for specific areas of the target ontology’s domain. This is accomplished by employing semantic search to locate resources, assessing their applicability, and contrasting them according to aspects such as cost, clarity, and quality. To speed up growth and raise the ontology’s overall quality, the best resources are picked and assembled25.

Ontology assessment

For the assessment of our ontology, we created an Ontology Requirements Specification Document (ORSD). It helped us analyze the domain, scope, and competency questions to make sure that our ontological resources met the needs.

Eye disease ontology requirements specification document

  1. 1.

    Purpose: EDO aims to establish a structured framework for systematically classifying and representing information about common eye diseases and disorders. EDO contributes to enhanced clinical decision-making, research efforts, and patient education.

  2. 2.

    Scope:The scope of the EDO comprises a variety of common eye diseases and their varied forms. Additionally, it includes thorough information regarding the medical signs, causes, symptoms, risk factors, diagnostic tests, and potential treatments linked with these medical conditions.

  3. 3.

    Implementation Language:EDO is implemented in OWL language.

  4. 4.

    Intended End-Users:

    • User 1 Doctors (Dr)

    • User 2 Patients (pt)

    • User 3 Medical Student (med st)

    • User 4 Common Person (CP)

  5. 5.

    Intended Users:

    • Use 1 : To consult about specific cases of eye diseases.

    • Use 2: To explore a medical condition that the patient is experiencing.

    • Use 3: To gain knowledge about different eye diseases.

    • Use 4: To better understand eye diseases and communicate efficiently with healthcare providers.

  6. 6.

    Ontology Requirements:

    1. a.

      Non-Functional Requirements:

      • NFR1. The ontology is consistent and should be able to answer the competency questions.

      • NFR2. The ontology satisfy the FAIR (Findable, Accessible, Interoperable, Reusable) principles.

    2. b.

      Functional Requirements: Groups of Competency Questions

  7. 7.

    Competency Questions:

    • Group 1: Disease Symphony

      • CQ1.1. What can be the differential diagnosis of primary open-angle glaucoma? (Dr)

      • CQ1.2. What are the symptoms of a patient having wet AMD? (Pt)

    • Group 2: Etiological Factors

      • CQ2.1. What are the factors that increase the risk of primary open-angle glaucoma in a person? (CP)

      • CQ2.2. What are the causes of patients having wet AMD? (Pt)

    • Group 3: Treatment

      • CQ3.1. Which drugs are recommended for a patient having primary open-angle glaucoma? (Pt)

      • CQ3.2. What is the drug class of bevacizumab drug? (med st)

    • Group 4: Medical History

      • CQ4.1. What previous medical conditions did the patient have, if he/she developed glaucoma? (CP)

      • CQ4.2. What are the factors that contribute to the development of glaucoma? (med st)

    • Group 5: Clinical Procedures

      • CQ5.1. What is the surgical procedure commonly done for primary open-angle glaucoma? (med st)

      • CQ5.2. What is the follow-up recommended for a patient having POA glaucoma? (Dr)

    • Group 6: Clinical Manifestation

      • CQ6.1. What are the findings of slit lamp examination for a patient having primary open-angle glaucoma? (med st)

      • CQ6.2. What is the finding of a Gonioscopy for a patient having primary open-angle glaucoma? (med st)

    • Group 7: Medical Device

      • CQ7.1. Which diagnostic device is used to do auto refraction? (med st)

      • CQ7.3.Which diagnostic device is used to diagnose wet AMD? (med st)

    • Group 8: Person

      • CQ8.1. What are the prescribed eye drops for glaucoma? (Pt)

      • CQ8.3.What is amblyopia? (Pt)

      • Summary of the Ontology Requirements Specification Document for Eye Disease Ontology

Ontology comparison

In the healthcare domain, many medical ontologies have been created with diverse objectives, such as the Human Disease Ontology (DOID)26, which organizes and defines human diseases based on their possible causes, symptoms, genetic factors, and more. It includes similar classes as used in EDO, such as disease and symptom, which include subtypes of diseases and their symptoms. The Human Phenotype Ontology (HPO)27 is another ontology that organizes and sorts human diseases based on the phenotypic traits that can be seen in human genes. These ontologies provide a general description of diseases based on their etiology and phenotype, respectively, but they do not go into detail on disease assessment or treatment, which is what we included in EDO. In HPO, there are equivalent classes as used in our ontology like are past medical history.

There is another ontology in which each different clinical concept is represented by a perception with a unique identifier in SNOMED CT’s available at https://bioportal.bioontology.org/ontologies/SNOMEDCT hierarchical classification system. Concepts are arranged into hierarchies and related through relationships that reflect their semantic connections. It has a semantically developed vocabulary for supporting healthcare decisions, but it does not provide a proper assessment of eye diseases, but EDO does. It contains several classes, some of which are equivalent to EDO, such as procedure, which we used in our ontology as a medical procedure which refers to procedures used in healthcare. NCIt: available at https://bioportal.bioontology.org/ontologies/NCIT is a biomedical ontology used to organize and standardize medical-related concepts and terminology. The NCIt is a terminological resource for cancer research, clinical practice, and information management. The NCIt classifies ideas according to their anatomical locations in the body. Overall, the NCIt’s classification system is intended to provide a comprehensive framework that helps researchers, clinicians, and others that accurately describe, organize, and communicate information. This ontology contains many equivalent classes, as in EDO, like disease, sign, finding, and current medication. Orphanet Rare Disease Ontology (ORDO)7 was created to give a systematic vocabulary for rare diseases. ORDO captures correlations between diseases, genes, and other relevant aspects that will be valuable for rare disease computational research. There is an equivalent class of disorder that contains various rare disorders, although we choose to use medical conditions reused from the schema. This ontology classifies rare human diseases, whereas EDO examines and assesses common ocular diseases in depth. ORDO presents a classification of rare human diseases, whereas EDO covers a complete examination and assessment of common ocular diseases. The Ocular Immune-mediated Inflammatory Diseases ontology (OCIMIDO)19 is an ontology specifically designed for inflammatory diseases related to the eyes, including their classification, investigation, and therapeutic intervention based on patient-preferred terms. OcIMIDo contains many classes that are similar to EDO, such as complications, which are used as medical conditions in EDO and contain different diseases as subtypes, they have used the clinical feature class, which contains different signs and symptoms and we have reused MedicalSignOrSymptom from schema as we prefer it for the same purpose that class contains different signs and symptoms of eye diseases. This ontology does not provide a comprehensive assessment of commonly occurring eye problems, as in EDO.

Inherited retinal dystrophy (IRD): available at https://bioportal.bioontology.org/ontologies/IRD presents a novel classification of hereditary ocular diseases that involves different layers of the posterior ocular segment. They categorize them into subclasses based on clinical and genetic characteristics. They present a general classification of disorders; however, full examination of a disease with symptoms, treatments, is not mentioned which is covered by EDO. No class or subclass is equivalent to EDO. Online Mendelian Inheritance in Man (OMIM): available at https://bioportal.bioontology.org/ontologies/OMIM demonstrates the hierarchical classification of anatomical diseases. OMIM presents a structured and organized way to categorize diseases according to human body organs. In this ontology, comprehensive categorization is performed, but it lacks a thorough investigation of diseases based on their symptoms and clinical findings.

The Mammalian Phenotype Ontology (MPO): available at https://bioportal.bioontology.org/ontologies/MPO classifies phenotypes using a hierarchical structure that describes a variety of observable features and attributes. For example, the MPO categorizes vision/eye phenotypes as abnormal eye morphology and abnormal eye physiology. It provides a thorough distribution based on phenotypes but does not include symptoms, treatments, and complete disease analysis that EDO has done for common eye diseases. Sickle Cell Disease Ontology (SCDO): available at https://bioportal.bioontology.org/ontologies/SCDO is the ontology that represents the hierarchical representation of medical knowledge, including disease classifications, genetics, treatment, complications, and more. Many classes are equivalent to our ontology, such as treatment, diagnosis, disease, and medical devices. It is shown in tabular form in Table 1.

Table 1 Reused ontology resources.
Full size table

Ontology selection

We chose various components of our ontology from several repositories, the most important of which is schema.org, and we reused many classes, subclasses, and properties from them. The classes reused are as follows:

  • schema:Patient

  • schema:MedicalProcedure

  • schema:DiagnosticProcedure

  • schema:MedicalCondition

  • schema:MedicalConditionStage

  • schema:MedicalCauses

  • schema:MedicalSignOrSymptom

  • schema:RiskFactors

  • schema:MedicalDevice

  • schema:NoninvasiveProcedure

  • schema:MedicalSign

  • schema:Drug

  • schema:DrugClass

  • schema:PhysicalExam

Similarly, different object properties are reused from schema.org, such as

  • schema:identifyingExam

  • schema:stage

  • schema:drug

  • schema:diagnosis

Also, the data properties are given below

  • schema:givenName

  • schema:suggestedAge

  • schema:frequency

  • schema:followup

  • schema:differentialDiagnosis

A record demonstrating the number of total classes reused from existing sources like schema, existing medical ontologies, and medical standards, is shown in Table 2.

Table 2 Ontology-aligned categories of eye diseases in EDO.
Full size table

Ontology integration

Ontology integration is an important phase in developing comprehensive ontologies that bring together disparate sources of domain knowledge. Protege, a popular ontology building and management tool, makes it easier to integrate ontologies by offering a strong foundation for merging, aligning, and merging ontological structures. Users can import existing ontologies into Protege and map concepts and links between them. This is accomplished by including prefixes in the ontology prefixes section and inserting the URIs of ontologies or repositories that need to be reused. To reutilize different components from schema.org, for example, we must insert its URI in protege so that we can reuse it by assessing it through its specific prefix, such as schema: By adding this, the IRI will change. This will incorporate that ontology or repository into your existing ontology.

Eye disease ontology modeling and conceptualization

Ontology modelling and conceptualization are important undertaking that involves the creation of a formal representation of a specific knowledge domain. It involved the process of creating entities, their attributes, and relationships with their interconnections. The primary objective was to develop an ontology that meets several fundamental principles, ensuring its effectiveness and usefulness, such as accuracy, consistency, completeness, well-structured, and user-friendly. By adhering to these key principles, design could be effective for ontologies to enhance knowledge representation and facilitate meaningful interactions within the designated domain.

Disease coverage in EDO

EDO focuses on a well-structured hierarchy of common eye diseases, including age-related, congenital, infectious, autoimmune, and refractive error categories. The ontology currently includes age-related macular degeneration (AMD) with its subtypes (DryAMD and WetAMD), cataracts (Nuclear Sclerotic and Posterior Subcapsular), glaucoma (including Primary Open/Closed Angle and Secondary types), refractive errors (Myopia, Hyperopia, Astigmatism, and Presbyopia), and eye movement disorders (Nystagmus, Strabismus, Amblyopia). It also incorporates conjunctivitis, uveitis (Anterior and Posterior), and extends coverage to other clinically relevant conditions such as viral keratitis and thyroid eye disease, as shown in Table 3.

Table 3 Data properties with their domain and range.
Full size table

In total, EDO covers a comprehensive and clinically representative set of ocular conditions. The selection was informed by disease prevalence reported in global health resources (e.g., WHO, AAO), expert ophthalmologic input, and diagnostic significance in general and specialised clinical settings. While rare or highly specialized diseases were generally excluded, exceptions were made for conditions like viral keratitis and thyroid eye disease due to their clinical impact and relevance.

Classes in EDO

In EDO, classes were added to categorize symptoms, causes, diseases, medical devices, risk factors, medical signs, diagnostic tests, and treatments. Classes were leveraged from the schema.org vocabulary to establish a robust framework for representing concepts and entities related to eye disease. Furthermore, sub-classes were added where explanation is required.

Data properties

Within the EDO, the characterization of classes is accomplished through the utilization of data properties. These properties are important for specifying the data values that can be assigned to instances of a class. Details of domain and range of data properties are enlisted in Table 3.

Object properties

Relationships between classes are established in ontology using object properties. In the EDO several object properties have been defined to establish the relationships among concepts and terms. Details of these object properties are shown in Table 4.

Table 4 Object properties with their domain and range.
Full size table

Property restrictions

Property restrictions are used to specify limitations and guidelines for the interactions between classes and individuals. To improve the quality and usefulness of ontology modeling, limitations are based on the technological information now available to help guarantee that data complies with defined requirements. In EDO property restrictions are defined in Fig. 1.

Fig. 1
figure 1

Property restrictions.

Full size image

Instances creation

In EDO, we have included several instances or individuals to represent real-world objects related to a specific class. For example, for the class of past medical history, different instances were added such as hypertension, smoking history, Appendectomy, and hypercholesterolemia. Details related to instances are shown in Fig. 2.

Fig. 2
figure 2

Instances.

Full size image

EDO modules

EDO has been categorized into eight distinct modules that include Person, Clinical Manifestation, Disease Symphony, Etiological Factors, Medical Device, Medical History, Treatment, and Procedures. Here is the brief overview of each of these modules.

Person (Patient)

A patient class from schema.org is reused to manage patient-related information. Patient’s class contains data properties from schema.org such as givenName, suggestedAge, suggestedGender, and telephone. This class has object properties schema : diagnosis and hasSymptom. Details of person is shown in Fig. 3.

Fig. 3
figure 3

Person module.

Full size image

Etiological factors

Etiological Factors are divided into Medical Causes and Medical Risk Factors. Classes details are shown in Fig. 4.

Fig. 4
figure 4

Etiological factors module.

Full size image

Medical cause

Medical causes are the factors responsible for a disease mechanism that results in a medical condition, symptom, or sign. This class is reused from schema. This class has an object property isCausedBy.

Medical risk factors

A risk factor refers to anything that increases a person’s probability of acquiring a disease, medical condition, or complication. The schema : MedicalRiskFactor class is reused from schema.org and has an object property triggeredBy.

Disease symphony

Disease Symphony contains two main classes as shown in Fig. 5.

Fig. 5
figure 5

Disease symphony module.

Full size image

Medical condition

schema:MedicalCondition class is reused from schema.org with subclass DiseaseOrDisorder and schema:MedicalSignOr Symptom. The DiseaseOrDisorder class that is reused from NCIT covers all diseases and disorders; there is also an Infectious Diseases subclass to separate infectious diseases from other diseases. It has an object property schema : stage. It has attributes like schema : differentialDiagnosis, schema : possibleComplication, andSchema : expectedPrognosis used as data properties. schema : MedicalSignOrSymptom is taken from the schema and is further subdivided into Medical Sign and Symptom. There are two subcategories of schema : MedicalSign. The terms schema : vitalsign and sign refer to the measurements of numerous physiological functions to analyze the most basic body functions, whereas signs are any physical manifestation of a person’s medical condition that can be discovered through objective diagnostic tests or physical examination.

The medical sign has the schema : identifyingExam object property. Both schema : MedicalSign and schema : VitalSigns are reused from the schema. Furthermore, the Symptom class that is reused from DOID contains many symptoms as subclasses for their particular medical conditions. Symptoms are the exact signals that a person experiences in their body that help to diagnose a particular disease. This class has one object property called schema : signOrSymptom.

Medical condition stage

It indicates what stage the Medical Condition is in. This class has an object property stage with the Medical Condition class.

Clinical manifestation

Clinical Manifestation has two sub modules that are clinical finding and clinical device as shown in Fig. 8.

Clinical finding

The clinical finding class includes subclasses that pertain to specific observations or outcomes discovered during various ocular medical examinations or health assessments of a patient. This class is reused from SNOMED CT ontology.

Clinical device

This module includes the class schema:MedicalDevice that organizes medical devices based on their usage. It has an object property :usesDevice. The medical device class is further separated into two subcategories and shown in Fig. 6.

Fig. 6
figure 6

Clinical devices module.

Full size image

Diagnostic device

Devices used for diagnostic purposes are included in the Diagnostic class.DiagnosticDevices are re-utilized from scdo ontology.

Therapeutic devices

The equipment utilized for treatment is in the Therapeutic class.TherapeuticDevices are re-utilized from scdo ontology.

Medical history

Medical History is divided into current medication and past medical history as shown in Fig. 7.

Fig. 7
figure 7

Medical history module.

Full size image

Current medication

Current Medication class refers to any medications, supplements, or drugs that the patient is already taking or it’s a part of their treatment plan. This class has an object property isCurrentlyOn.

Past medical history

Past Medical History class mentions the record of a person’s medical conditions, surgeries, accidents, and medications. This class has an object property hasMedicalHistory (Fig. 8).

Fig. 8
figure 8

Clinical manifestation module.

Full size image

Treatment

Drug

A schema:drug class refers to substance that is used to treat a disease. This class is taken from schema. It has an object property schema:drugClass.

Drug class

The schema:DrugClass is reused from schema.org and it refers to a group of medicines that indicate common physiological effects, common processes of action, or general pharmacological classes.

Dose schedule

schema:DoseSchedule class reused from the schema describes the specific schedule to take the drug. It has schema:doseUnit, schema:doseValue, schema:frequency, and schema:targetPopulation data properties. These data values show how and when to take the medicines or drugs. It has an object property schema:doseSchedule.

Noninvasive procedure

The schema:NoninvasiveProcedure class contains diagnostic or therapeutic methods that don’t require tools to be inserted into body cavities or to penetrate the skin. This class is reused from schema.org.

Clinical procedures

Clinical Procedure has three modules diagnostic procedures, physical exam and surgical procedure details are shown in Fig. 9.

Fig. 9
figure 9

Clinical procedures module.

Full size image

Diagnostic procedure

In the schema:DiagnosticProcedure class, all those medical procedures are included that are used to diagnose any particular disease or condition. It has an object property detects.

Physical exam

schema:PhysicalExam class refers to examinations carried out by a physician. This class contains an object property schema:identifyingExam.

Surgical procedure

The surgical procedure class includes the processes that involve making an incision. It has an object property hasSurgicalProcedure.

Ontology metrics

Ontology metrics contain the summary about the number of Axiom, logical axiom, Classes, objects,data properties count, individual count, and Annotation properties. Summary is shown in Table 5.

Table 5 Ontology metrics.
Full size table

Integrating use case into ontology

In this section, we present a comprehensive case study of an ophthalmic patient to demonstrate how semantic ontology can streamline clinical decision-making. The case is analyzed across three critical stages: Patient History, Diagnosis, and Treatment. Each phase illustrates how structured knowledge representation enhances clarity, accuracy, and continuity in patient care.

Patient history

The Patient History phase involves a structured understanding of a patient’s background, medical history, and current medications that may contribute to disease development. This foundational step is essential for assessing risk factors and guiding further clinical evaluation.

The patient is a 61-year-old retired educator who has not undergone an eye exam in the past decade. She uses glasses for near tasks and reports moderate eye irritation, particularly in the afternoon or after prolonged reading. Her Past Medical History includes presbyopia, hypertension, a history of eye trauma, and one cesarean delivery. Her Current Medication includes Hydrochlorothiazide. These details are illustrated in Fig. 10.

Fig. 10
figure 10

Use-case of patient medical history.

Full size image

Diagnosis

The Diagnosis phase integrates clinical observations, diagnostic procedures, and semantic associations to enable accurate identification of disease. Ontological models help structure these findings clearly and meaningfully.

To determine the cause of the patient’s symptoms, several Medical Procedures were conducted. Based on the Clinical Findings, the patient was diagnosed with Primary Open-Angle Glaucoma (POAG). The diagnosis was supported by the following Medical Signs: elevated intraocular pressure, abnormal optic nerve head, open anterior chamber angle, and visual field deficits. These diagnostic indicators are presented in Fig. 11.

Fig. 11
figure 11

Use-case of disease diagnosis.

Full size image

Treatment

The Treatment phase categorizes both pharmacological and surgical interventions and incorporates follow-up recommendations to optimize patient care and long-term outcomes.

To reduce intraocular pressure, the patient was prescribed topical medications, including Timorex, Latep Eye Drops, and Azm Pills. An alternative surgical intervention, Trabeculectomy (classified as a schema : SurgicalProcedure), is also recommended depending on disease progression and drug response, as shown in Fig. 12. For ongoing care, regular IOP monitoring, visual field testing, and optic nerve assessments are essential, as outlined in the schema : followup phase.

Fig. 12
figure 12

Use-case of treatment.

Full size image

This case illustrates how the applied ontology effectively supports all three stages of clinical decision-making. It allows structured representation of patient history, facilitates semantic integration during diagnosis, and categorizes treatment options with follow-up care. This layered and semantically rich model enhances the interoperability of health data and empowers informed, precise decision-making in ophthalmic care.

Conducting domain expert validation

In addition to the described technical validation methods, qualitative evaluation of the Eye Disease Ontology (EDO) was conducted through expert consultations with ophthalmologists at DHQ Hospital, Sargodha: available at Dr. Hashim Imran & Dr Jannat. These discussions provided critical insights into real-world diagnostic and treatment workflows, enabling the ontology to accurately reflect clinical practices. Feedback from these domain experts guided the refinement of EDO’s class hierarchy, data properties, and object properties, thereby enhancing its completeness, accuracy, and applicability in real-world ophthalmic contexts.

Evaluating ontology

After the creation of the ontology, we critically analysed its structure, relationships, and semantics to uncover any potential flaws or inconsistencies that may have been inadvertently introduced during development. A comprehensive self-assessment was conducted to ensure alignment with the ontology’s intended purpose. Following this, we employed the Ontology Pitfall Scanner (OOPS!) to further evaluate the ontology. This tool detects common modelling issues, inconsistencies, and deviations from best practices that may not be identified through manual inspection.

The majority of the issues identified by OOPS! were resolved during our refinement process. Specifically:

  • Resolved by adding clear labels and annotations to all classes, object properties, and data properties.

  • P11-Missing Domain or Range in Properties: Addressed by explicitly specifying domains and ranges for all properties.

  • P30-Equivalent Classes Not Explicitly Declared: Resolved by declaring equivalence for classes such as Fatigue and Tiredness.

Initially, three minor issues were flagged by OOPS! remained:

  • Untyped Class,

  • Ontology Not Available on the Web, and

  • No OWL Ontology Declaration.

These issues have now been fully addressed and resolved. The untyped class was properly typed, and the ontology is now hosted with a dereferenceable IRI accessible on the web to comply with OOPS! expectations, and the OWL ontology declaration has been added. These updates ensure the Eye Disease Ontology complies with best practices for ontology publishing and improves its interoperability and accessibility. The ontology pitfalls summary is shown in Table 6.

Table 6 Ontology Pitfalls.
Full size table

Ontology GitHub repository link

To meet the FAIR (Findable, Accessible, Interoperable, Reusable) principle, which is important in making ontologies more accessible, discoverable, reusable and interoperable, makes it easier to get information, collaborate on research, integrate data, and convey knowledge. Ontologies that are FAIR-compliant are more likely to be broadly adopted and used, promoting improved data sharing and collaboration. For this purpose, the source file of the ontology is made available on Github: available at https://github.com/fatima333-ai/EyeDiseaseOntology/tree/main to make the ontology more findable and accessible, ensuring that users can effortlessly discover it. Moreover, we generated the load document. It will emphasize reusability since reusable ontologies can save both time and effort for both ontology creators and users. Making the ontology available to users will help new users get started from scratch, promote consistency, and reduce redundancy.

Executing SPARQL queries

SPARQL enables users to write complex queries that extract important information, discover relationships between entities, and answer domain-specific questions within ontologies. The Eye Disease Ontology (EDO) was created as a structured knowledge base to support queries related to diagnostic techniques, symptoms, causes, risk factors, and therapies for various eye conditions. Based on the defined use case, we created SPARQL queries and ran them against EDO. The matching questions are shown in Table 7.

Table 7 SPARQL queries against competency questions.
Full size table

The SPARQL queries conducted on EDO predominantly employed the SELECT and WHERE clauses, with some also including FILTER conditions. As the number of filters and constraints increased, the complexity of the queries ranged from medium to high. This increase in expressiveness sometimes led to longer execution times, although overall response efficiency remained moderate, largely influenced by the quality of the underlying data and the effectiveness of instance matching.

We executed SPARQL queries for all 40 competency questions (CQs) presented in the manuscript. However, due to space limitations, only a representative subset is included in the paper to demonstrate the querying process and practical utility of the ontology. These CQs spanned multiple categories, and 38 of them produced correct and expected results. The two that initially failed highlighted gaps in the ontology, prompting refinement through the addition of missing axioms and adjustment of class relationships to enhance reasoning and coverage. Average SPARQL execution times for the sample queries ranged from 80 to 150 milliseconds, indicating efficient performance suitable for clinical decision support. Additionally, we clarify that ambiguous answers were not encountered during testing. If a query did not return the expected result, it was due to syntactical errors or logical gaps in the ontology, which led to execution errors or empty responses. These cases were systematically addressed during iterative development to improve the accuracy, reliability, and completeness of EDO.

Conclusion & future work

We have proposed the Eye Disease Ontology (EDO) for common eye diseases, which serves as a robust knowledge framework to organise and categorise symptoms, causes, risk factors, diagnosis and treatment options for eye diseases. In this research, the developed ontology EDO makes significant contributions to the field of ophthalmology, including enhanced diagnostic capabilities and patient care, as well as the facilitation of cutting-edge research and data interoperability. Using the NeOn methodology, we developed the EDO ontology, which includes 566 classes, 16 object properties, 12 data properties, and 119 instances. Among these, 25 classes were reused, 17 from schema.org and 8 classes from other existing ontologies. Furthermore, we reused 12 data properties and 5 object properties from schema.org. The entire development process was carried out within the Protégé environment. To determine the precision and accuracy of our ontology, we integrated use cases and competency questions, while SPARQL queries were used to retrieve information from our ontology. In addition, the OOPS Pitfalls Scanner was used to further validate EDO.

Future work: We intend to use the Eye Disease Ontology (EDO) to create a knowledge graph that includes semantically linked real-world scenarios, greatly enhancing EDO’s usefulness. In addition, EDO can be used to define essential clinical entities, allowing for the construction of scalable systems for automated eye disease detection. Future studies will focus on implementing semi-automated updating methods to incorporate new diseases, therapies, and surgical techniques, ensuring that the ontology remains current and therapeutically relevant. This will facilitate advanced research and clinical decision-making in ophthalmology.