Ontology and tool development for documenting intraoperative monitoring in neurosurgery

doi:10.21203/rs.3.rs-2026582/v1

Download PDF

Research Article

Ontology and tool development for documenting intraoperative monitoring in neurosurgery

https://doi.org/10.21203/rs.3.rs-2026582/v1

This work is licensed under a CC BY 4.0 License

Version 1

posted

You are reading this latest preprint version

Background: Intraoperative neurophysiological monitoring (IOM) is intended to serve as an early warning system. By measuring evoked potentials during neurosurgical procedures IOM aims to determine when tumor tissue removal must be stopped to avoid damage to important structures such as the corticospinal tract. The central objective of this work is to provide an ontology that improves interrelated documentation in terms of adequate event characterizations. In contrast to a taxonomy (or meronomy), an ontology enables semantic enrichments of documentation events by modelling relationships beyond is-a or part-of, e.g., causally-related-to or occurs-in. This enhances documentation accuracy as well as the potential of useful inferences. Given our focus on extensibility and the desire to reuse existing ontologies as much as possible, we decided to use the basic formal ontology (BFO).

Results: Our work has three central results: (i) an BFO-based ontology for IOM that is extended to a knowledge base, (ii) a software tool with a graphical user interface that goes beyond Protégé to involve the experts of the IOM subject field, (iii) and an evaluation of the tool in real-world documentation scenarios that allowed us to derive necessary adaptations for its productive use. The core entities of the ontology are measurements with the components timestamp, measurement type, measure values, and measurement location. We did not use the ontology of adverse events because its reliance on describing events solely as occurrents was not fully compatible with our use case of representing the documentation of those events. One crucial insight is: Occurrents such as processes are generally designed to track general dynamics, rather than to identify and document concrete processes related to individuals. Several ontologies were embedded into our ontology, e.g., the Foundation Model of Anatomy (FMA), the Human Phenotype Ontology (HPO) and the ontology for surgical process models (OntoSPM) related to general surgical terms. Our software tool was developed based on JavaFX for the frontend and Apache Jena for the backend. In the evaluation, all participants agreed that the interface could be used without having extensive technical skills.

Conclusions: Basing our ontology development on BFO facilitated the start of the ontology development. It also simplifies integration of other ontologies. For example, it was highly helpful to be able to integrate parts of domain-specific BFO-based ontologies such as OntoSPM. By creating a knowledge base for IOM, investigations on event-outcome associations, e.g., “a signal change pattern X before an event Y is causally related to the outcome Z” are enabled on a semantically enriched data base.

BFO

ontology

knowledge base

neurosurgery

adverse events

Apache Jena.

During surgical resection of brain tumors, it is a challenge to distinguish between healthy and pathological brain tissue. Even more important, functional areas such as motor, sensory or language areas and tracts are not visually identifiable for the neurosurgeon. A lesion of these regions may result in a postoperative neurological deficit, e.g., motor paralysis, and affect the quality of life significantly. The use of intraoperative neurophysiological monitoring (IOM) with continuous measurements of neural activity during surgery reduces the risk of such deficits. IOM includes mapping techniques, which are used to locate functional areas, as well as continuous functional monitoring, which is useful for assessing functional integrity. By measuring evoked potentials, the surgical strategy can be adjusted in real time to prevent impending functional impairment [1–4].

For example, motor evoked potentials (MEPs) are used to monitor indirectly motor function. They are measured at the beginning of the surgery (so-called baselines) as a reference for subsequent stimulations. If the MEPs remain stable during surgery, it is an indication that there will be no permanent motor deficits. However, if there is signal change or loss (a warning criterion), postoperative motor deficits are to be expected. MEPs can be measured by transcranial electrical stimulation (TES) through scalp electrodes or by direct cortical stimulation (DCS) through strip electrodes (grids) placed in the central region of the brain cortex [3, 5]. See Fig. 1 for a visualization of the motor pathways.

At the Department of Neurosurgery, University Hospital Bern, Inselspital, the current documentation IOM workflow is paper-based. The documentation consists of a protocol with patient and surgical information as well as neurophysiological, surgical and anesthesiologic events. Each event is time-stamped. An event describes, for example, the neurophysiological baseline measurement of different evoked potentials and later their amplitude or latency change in signal measurement during surgery. An event can also be the process of tumor removal. There is currently no common standard for the documentation of IOM protocols and documentation quality depends heavily on the experience of the documenting person [3]. The mainly paper-based workflow makes querying the data difficult and leads to redundant information, which increases the susceptibility to errors.

As a first step towards standardizing documentation and digitizing the whole IOM documentation workflow, a JavaScript-based web application (IOM-Manager) was developed [6]. The primary goal of the IOM-Manager is to optimize the data entry process during surgery. To facilitate documentation of events, a catalog with 4 main categories and 25 subcategories was developed [7]. Even though the IOM-Manager received positive feedback, it did not efficiently address issues of extensibility and knowledge discovery. One major reason was the lack of semantic relationships between different types of entities. This triggered our decision to develop an ontology and our change of focus with respect to the data entry process. Here, the focus is not on documentation during surgery, but on building a knowledge base, including instances of ontology classes, which in the long run should be the basis for a software such as the IOM-Manager.

The central objective of this work is to turn the preliminary entry catalog of the IOM-Manager into an ontology that enhance the documentation in terms of adequate event characterizations and allows to automatically infer interesting associations. In contrast to a taxonomy (or meronomy), an ontology enables semantic enrichments of events by modelling relationships beyond is-a or part-of, e.g., causally-related-to or occurs-in. Again, this enhances documentation accuracy as well as context-based queries (the repetition is made due to a question of a reviewer). In the end, the quality of the event documentation will increase, automatic inferences are enabled, and data integration facilitated. To allow non-technical users to enter and query instances in the ontology, a prototype for a graphical user interface is being developed as well. Tools for ontology development, such as Protégé [8], ROBOT [9] or APIs such OWL API [10] are tailored for the technical support of extensible ontology development. For involving non-technical expert domains into the development process, these tools are often not useful. However, the involvement of these users beyond personal interactions is important, as the objects in the knowledge base will be entered by them. By providing context-dependent suggestions in this entering process they can comment on the usefulness of categories and possible adaptations. Thus, we will describe both the ontology and the software development in this paper. Our assumption is that ontology development will benefit from simple user-interfaces for experts in the field. The software prototype is not intended to support documentation during surgery, which is intended as a future project that merges our prototype with the IOM-Manager.

Due to our focus on extensibility and the desire to reuse existing ontologies as much as possible, we have decided to use the basic formal ontology (BFO [11]) as a starting point. BFO is a top-level ontology designed to support the acquisition, analysis, and integration of information in scientific domains, and it is used by over 250 ontology-driven projects worldwide. Thanks to its generality and manageability, it is well suited as a starting point for building subject-specific ontologies [12]. The fundamental distinction of BFO is between continuants, i.e., those entities that persist over time and are fully present at any point in time at which they exist (e.g., material entities), and occurrents, i.e., those entities that unfold in time and are present at any time only through their parts, e.g., the stages of diseases. There are two relevant alternatives to BFO: (i) The Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE [13]). As the name indicates, its focus is on human language and intends, for example, to clarify the hidden assumptions underlying existing ontologies or linguistic resources such as WordNet [14]. (ii) The Unified Foundational Ontology (UFO [15]). It is designed as a foundation for general conceptual modeling languages such as OntoUML [16], DOLCE and the general formal ontology (GFO [17]). DOLCE and UFO as well as their underlying principles – reflected to a large extent in GFO – are not as widespread as BFO in the biomedical domain. We attribute this to the fact, that BFO was primarily developed with biomedical expert domains, which allowed swift adoption, e.g., for the gene ontology [18]. Even though all upper-level domains have philosophical underpinnings, BFO tried to reduce the theory-practice gap right from the start and was less focused on formalizations or topics such as sortal-relativity or rigid designators. This is one major reason for having an BFO-ISO standard since the end of 2021 [19].

In our preliminary research on relevant ontologies, we found the ontology of adverse events (OAE [20]), and it was crucial to assess whether we could rely on it to cut things short. Instead of discussing OAE and other potential ontologies in the introduction, we decided to discuss them in Step 4 “Ontology Reuse’’ of our approach to ontology development, as ontological research per se is a highly interrelated activity, which immanently covers review and reuse of previous results in its methodological approaches.

We planned three phases for the development of our ontology-based tool. In the first phase, the ontology was developed according to the OBO (open biological and biomedical ontologies) principles [21]. One implication is, for example, the requirement that all entities must have a unique Internationalized Resource Identifier (IRI), composed of a base, as prefix and a local identifier (e.g., BFO0000001). In the second phase, the software for the non-technical documentation was developed in an agile manner to capture all relevant requirements and produce a prototype in a short period. In the last phase, we evaluated the tool in real-world documentation scenarios and derived necessary adjustments for productive use.

2.1 Ontology development

The development of the ontology was carried out in seven steps [22]. As a development environment, we used the Ontology Editor Protégé Version 5.5.0, which supports the web ontology language OWL2 (https://I.stanford.edu/products.php). To find and integrate relevant entities from other ontologies, we used the web-based tool Ontofox (http://ontofox.hegroup.org/). After every substantial enhancement, the HermIT reasoner was run to check consistency [23]. In the following, the steps are outlined in detail.

Step 1: Determine the scope of the ontology

As suggested by Noy and McGuinness, we determined the scope of the ontology by answering the following two questions:

What are the use cases for the ontology?
Who will use and maintain the ontology?

To answer the first question, competency questions were formulated together with the IOM team at the Inselspital hospital, allowing us to understand what type of queries the ontology needs to answer. The second question was preliminary answered during the formulation of the competency questions and finally fixed during requirement engineering in the software development phase.

Step 2: Defining the core terms in the ontology

To define the core terms in our ontology, we first manually analyzed five IOM protocols, primarily to determine the most relevant documented events. The protocols were analyzed based on their structure and recurring terms. Then, we checked for overlapping with the hierarchical catalog of terms developed in former work [7]. For any terms that did not overlap, we decided together with the physicians whether to skip, redefine or merge them. To gain a better insight into the documentation workflow and to validate our results, we also accompanied four experienced medical-technical assistants during surgery at the Inselspital. Observing when and how events were documented was crucial for understanding the dependencies involved.

Step 3: Designing the ontology

In this step, we determined the structure of the ontology. As we took BFO as a base, the general structure was predefined. However, it was crucial to define the location and hierarchy of the events in our ontology. Here we addressed the question of whether to use the occurrents (process boundaries) or the information object concept (generally dependent continuant) for the events. All other entities in our ontology must be related to these events in terms of documentation requirements. Regarding other terms in our ontology, we heavily relied on existing ontologies.

Step 4: Ontology Reuse

Reuse of existing ontologies was based on the MIREOT principle (minimum information to reference external ontology terms), which defines the minimum amount of information required for an imported entity to remain uniquely identifiable in the target ontology. MIREOT suggests importing only needed entities and not entire ontologies. While inferences and consistency checks might suffer from such a minimal strategy, integration of complete ontologies can also lead to inconsistencies and undesired side effects, in addition to bloating the target ontology [24]. Since we only used terms from BFO-based ontologies, the minimal strategy was the right way for us.

Step 5: Write annotations and axioms

To enhance the readability and extensibility of our ontology, we add a definition to each newly added entity. The annotation property “definition” is used for this purpose. In addition to that, some axioms were defined with the goal of improving consistency checking capabilities.

Step 6: Define Instances and their Object & Data Properties

Based on the available IOM controls, we included instances of the classes in the ontology, extending it to a knowledge base. Instantiated entities of the IOM ontology are characterized by object properties as provided by the Relation Ontology (RO [25]). Especially the relations between objects are important for queries about the documented entities. Data related to patients such as date of birth or case number are defined as data properties.

Step 7: Ontology Evaluation (satisfiability and consistency)

The consistency of our ontology is checked by HermIT, a highly efficient OWL reasoner that can classify a large range of ontologies. In addition, the software evaluation of our documentation tool provided insights into further syntactic and semantic problems of the ontology.

2.2 Software development

An ontology as presented in Protégé or similar environments cannot be used by a non-technical user without costly training efforts (e.g., to generate queries). To abstract from the complexity of the ontology and to facilitate the documentation of cases, a graphical user interface (GUI) was developed. The decision for the programming framework was mainly driven by its capabilities to integrate the ontology into a user-centered application. Five criteria were defined for this decision: supporting of SPARQL and OWL, portability, available documentation, and being license-free.

For the development itself, we first performed a requirements analysis, after which a software concept for our IOM documentation ontology (IOMDO) software was formulated, separated into frontend and backend. For the implementation of the frontend, we relied on a simple documentation workflow and context-sensitive dropdown menus to select the relevant entries (see also [7]). Regarding the backend, it was important to decide how to persist new instances, how to map the entries in the user interface to the ontology, and how to query the information within the ontology.

2.3 Software evaluation

To evaluate the software, we performed two types of tests: an input and a usability test. The former one evaluates whether the mapping between user entries and the ontology is valid, allowing to persist all cases as instances of the ontology. For this purpose, the contents of five IOM protocols were entered via the IOMDO software. In the case of missing or inappropriate terms, these were first noted and afterwards added or corrected within the ontology. The usability test was conducted with five members of the IOM team at the Inselspital hospital. A test scenario was defined, and the participants were asked to solve tasks in this scenario with the IOMDO software, while thinking aloud. We wrote down everything that was uttered during the test. Additionally, we required feedback by completing a SUS (system usability scale)-based questionnaire and scoring points [26]. A score above 68 was determined to be desirable [27]. Participants had no prior instruction on how to use the interface, which allowed us to assess whether features were used as intended without explanations. Moreover, it helps to identify what is absolutely needed as instruction for a productive use of the software.

3.1 The IOMDO ontology

The final ontology is available via GitHub: https://github.com/neues4/IOMDO. Here we describe the outcome of the seven steps in our ontology development phase.

Outcome of step 1: Scope of the ontology

The following competency questions are reflecting the central use cases and were derived in collaboration with the IOM team at Inselspital:

1. How did MEP thresholds/intensities change during surgery and what is the postoperative outcome?

2. What is a patient's lowest subcortical mapping threshold in correlation to postoperative outcome?

3. How are signal changes related to tumor pathology?

Therefore, the scope of the ontology can be formulated as the documentation of such events during surgeries using IOM. The ontology will be used by two types of users: those who derive knowledge from the ontology (mainly physicians) and those who document during surgery (mostly medical-technical assistants). Until the ontology is integrated in a commercial product, the maintainer of the ontology will be the Bern university of applied sciences, represented by the last author of this paper.

Outcome of step 2: The core terms in the ontology

The analysis of the five IOM protocols and the on-site observations during surgeries showed that the core of the documentation are measurements with the following components:

● Time stamp: The time at which the measurement takes place.

● Measurement type: Indicates which potential is measured and how it is stimulated.

● Measured value: The measurement response of the current intensity in mA.

● Measurement location: The muscle or nerve where the measurement takes place.

All other entities are associated with these measurements. The relevant section regarding measurements in the ontology is shown in Fig. 2.

Outcome of step 3: The ontology design

As it is important in our ontology to link measurements to adverse events after surgery, we first considered using OAE [20], which is also BFO-based. However, it became clear that OAE’s decision to classify events as occurrents was not fully compatible with our use case of representing the documentation of those events for specific patients. Occurrents such as processes are mostly destined to track general dynamics, not to identify and document concrete processes related to individuals. For example, if there is a decline of an evoked potential, we are not interested in describing the (general) process of this decline, but only in documenting this decline as an event. Hence, we modeled these events as generally dependent continuants in BFO and adopted the "Information Content Entity'' from the ontology for surgical process models (OntoSPM) [28]. In the context of documentation, an event is exactly an information content entity with reference to a real-world entity that has completely different identity criteria (an extensive discussion on identification of occurents versus continuants is provided in [29]). To further characterize these events, we created the entity “diagnostic finding”. In contrast to the entity “diagnosis”, each striking event is captured with this entity and not the causal reason for the operation in terms of the ICD code. Processes are used in our ontology only to indicate actions, which is motivated by the decisions for OntoSPM. Such action-focused processes represent a static view in contrast to depicting the dynamics, in the same manner as a hierarchy of business functions is contrasted with a process model. However, without our reliance on OntoSPM, we would also model actions as an information content entity. In the future, the dynamic process view can be included as well, but would increase the complexity significantly.

Outcome of step 4: Ontologies reused

For anatomical terms such as nerves and muscles, we referred to the Foundation Model of Anatomy (FMA). For disease terms, the main sources were the Human Phenotype Ontology (HPO) and the Mondo Disease Ontology (MONDO). Terms related to surgery were extracted from OntoSPM, which represents a core ontology for surgical processes in general and focuses on actions and their participants [28]. OntoSPM itself builds on existing ontologies such as the Information Artifact Ontology (IAO), the Ontology of Biomedical Investigations (OBI), and the FMA.

As measuring is a relevant concept, we also considered to re-use ontologies focusing on measurements. EngMath is an ontology for mathematical modelling and engineering, covering aspects of measurements primarily from the perspective of physical and philosophical measurement theory [30]. The Unified Code for Units of Measure (UCUM) is intended to include all units of measures being contemporarily used in international science, engineering, and business, thereby facilitating unambiguous electronic communication and exchange of quantities together with their units [31]. The Measurement Units ontology (MUO [32]) adapts the units and quantities of UCUM and provides URLs for them. It has therefore the same perspective: “units are abstract spaces used as a reference metrics for quality spaces, such as physical qualia, and they are counted by some number”. The most promising ontologies for us seemed to be the “Quantities, Units, Dimensions and Types” Ontology (QUDT, see [33] for an embedded presentation of it) and the Ontology of units of Measure (OM [34]). Both are practical and we learned a lot regarding the notions involved, e.g., that a basic record consists of (1) the phenomenon: object or event being observed (surgery), (2) the quantity kind (electric signal during surgery), (3) unity of measurement (mA), and (4) a numerical value. However, as none of these ontologies is BFO-based and due to the availability of standard units for measuring potentials, we decided not to re-use these ontologies for measurements in this project.

We also performed a search on ontologies covering reporting of events in the biomedical context beyond OAE. Many of these ontologies are basing their efforts on OAE, e.g., with respect to Drugs (ODAE [35]) Vaccine AEs (OVAE [36]), Drug Neuropathy AEs (ODNAE [37]), and Cardiovascular Drug AEs (OCVDAE [38]). For the same reasons provided regarding OAE and due to their specific perspectives, these ontologies were not useful for our case. Other biomedical ontologies are often older, not BFO-based and not maintained, for example, the clinical communication ontology for medical errors (OCCME [39]), ontology of Adverse Drug Reactions for Automated Signal generation Ontologies (OADRAS [40]), and the Adverse Drug Event Ontology (ADEO [41]). In conclusion, there seems to be no alternative to an BFO-based ontology for reporting events, which makes our work important from this point of view. Again: one should differentiate between an ontology for events and an ontology for reporting events, as the entities involved are different.

Outcome of step 5: Annotations and axioms

All entities in the IOM ontology have English and German labels and definitions. If available, the source of the definition is indicated with the anno“ation "definition”source". We added only two axioms (in Manchester OWL Syntax): for the entity “measurement data item”, the axiom “part of” (is) some “diagnostic finding“ is defined, and for the entity “diagnostic finding” its inverse “has part” (is) some “measurement data item” is defined.

Outcome of step 6: Instances with Object Properties and Data Properties

To create instances via Protégé, one must first click through the ontology tree to find the entities to be instantiated. Then, a new instance for an entity can be added and named. All relationships between instances must be created as well, which is prone to error due to the many possibilities to be selected by hand. In case of a wrong relation instance, the reasoner will issue an error message and the query will not produce correct results. In our IOMDO software, the user has only to enter the relevant events during an operation as well as the corresponding measured value. Relationship instances are created automatically based on the implemented logic. Hence, during instance creation, we used one important advantage of the IOMDO software compared to Protégé.

Five Object Properties have been defined to allow querying of the instances in the ontology. The "Patient" and "Surgery" entities have Data Properties that contain the logged patient and surgery information.

Outcome of step 7: Ontology evaluation (satisfiability and consistency)

Initially the relation (object property) “has measurement unit label” from OntoSPN was used to set a relation between a measurement datum and a unit. Due to its functional characteristics, there was a conflict with our modeling (see in Fig. 3). A functional property means that for a given individual there can be at most one value. However, we decided that a measurement datum (e.g., MEP measurement) can have multiple measured values, because this adequately represents the way the measurements are documented. This inconsistency was immediately detected by HermIT Reasoner when a MEP measurement had more than one measured value with its corresponding measurement units. This led to the solution of a new object property “has measurement unit” without the functional characteristic.

3.2 The IOMDO-based software

Table 1 gives an overview of the (backend) frameworks we considered and evaluated according to our five criteria: (i) support of SPARQL, (ii) support of OWL, (iii) portability, (iv) documentation, (v) type of license. Apache Jena was assessed to be the only tool to offer a framework that is flexible enough to cover our use case and allows seamless integration of a GUI with an ontology backend. For the frontend, we opted for JavaFX, which could easily be replaced by other Java frontend frameworks.

Table 1

Evaluation criteria for three frameworks for ontology handling in JavaScript and Java.
	TopBraid Composer Maestro Edition	RDF JavaScript Libraries	Apache Jena
Short description	IDE	Collection of libraries	Framework
Language	Java	JavaScript	Java
Supports SPARQL	Yes	Yes	Yes
Supports OWL	Yes	No	Yes
Portability	Platform independent	Browser, Node.js	Platform independent
Documentation	Available	Partially available	Available
License	3450 $ for 1 year	Open Source	Open Source

Based on our requirement analysis for the frontend, we decided to consider five tabs in the GUI: record protocol (default), view protocol, create query, view ontology, and user guide. In the “Record Protocol” view, the data to be recorded is divided into four categories (see Fig. 4):

● Patient and surgical data: Data related to general patient characteristics and the reasons for the surgery (will be imported in most of the cases).

● Baselines: The basic measurements of evoked potentials (e.g., MEPs) at the beginning of a surgery. Not all of them are needed in every surgery.

● Recorded events: This is where the actual recording takes place during or after surgery. Text can be entered freely in the fields “time”, “value” and “comment”. Dropdown lists are available for the fields “category” and “subcategory. The appearance of the fields “subcategory” and “value” is context-dependent.

● Postoperative disposition: A dropdown list is provided to indicate whether

a complication has occurred after the surgery, which must be connected to it.

In the example of Fig. 4, the recording starts with the selection of the category “IOM start”. The category “mapping measurement” is selected afterwards and then the subcategory “dynamic mapping measurement” (In German “Dynamische Mapping-Messung”). Measurements always require a value entry in mA. To end the recording, “IOM end” is selected. After clicking “Save” the record is saved within the ontology in the RDF/XML syntax. The saved RDF/XML can additionally be viewed in Protégé (see Fig. 5).

Figure 6 shows how records entered via the GUI are embedded into the ontology. The entity “Patient” is in relation “has document” with the entity “IOM document”. An IOM document consists of several data elements, to which the items entered in the GUI are mapped. For example, “dynamic mapping measurement” in the GUI is mapped to “measurement data item” in the ontology. The “surgery data” in the GUI is mapped to the entity “surgery”, which is subsumed to the “clinical data item” entity. The item “incision” (in German “Schnitt”) in the GUI is subsumed to “surgical process”. The entity “process observation data item” is needed as a link between a process and the data item of the document.

In the “create query” tab of the GUI (mostly used by physicians), two different types of queries are provided: predefined queries for the non-technical user (the query is executed in the background) and SPARQL queries for more technical users. To execute the first query type, a button at the end of a short description must be pressed, producing the results in a text field of the GUI, e.g., a list of all patients for whom adverse events were described. In the example of Fig. 7, this list contains information about the patient (last name, first name, date of birth), the diagnosis, the postoperative outcome, and the lowest mapping threshold. For the second query type, the user must formulate a valid SPARQL statement, which is then again executed by pressing the button at the right bottom corner next to the text field. Results can also be exported as csv-files.

In summary, the sequence diagram in Fig. 8 shows how the user interaction with the GUI is forwarded to the backend to store and query data in the ontology.

3.3 Software evaluation

The input test and the observations during the usability test allowed us to address deficits in the mapping between user entries and the ontology, e.g., we initially did not consider that in the case of selecting metastasis as a diagnosis it is crucial to add the location as additional information.

For the usability test, 4 of the IOM team members were included. One person could not participate due to lack of time. The average SUS score achieved was 75, with the best individual score being 97.5 and the worst being 50. Main reason for the worst score was a general discomfort with dropdown lists: scrolling down was rated as cumbersome and inconvenient when the list includes more than five items. A searchable list could address this issue in future. However, all participants agreed that the interface could be used without having extensive technical skills.

At the start of our ontology project, we envisioned to develop a knowledge base that could be used for the IOM-Manager software, which would combine our two goals: support of knowledge discovery and support of efficient documentation during surgery. However, it turned out that a graphical user interface beyond Protégé is crucial to involve the experts of the IOM subject field (see above for an explanation). To combine the two goals, further steps were now deemed necessary, beginning with establishing four kinds of settings and related criteria: (i) documentation during surgery: number of clicks, speed of entry, (ii) documentation and post-processing after surgery: finding the case quickly, simplicity of processing, (iii) querying and inferring information: interoperability of the terms used, inference capabilities, (iv) further development of the ontology: ease of extensibility, ease of versioning. To merge the IOM-Manager with the IOMDO software, these four settings with their different criteria should be supported with different workflows in a combined software tool to establish a comprehensive and integrative support system. For example, if a novel event is to be entered during surgery, it should trigger a post-processing workflow to expand the ontology while also efficiently guiding the documentation of the event through a standardized “new kind of event” capture mechanism. From a technical perspective, this kind of integration is not trivial, as the mappings into the ontology require more information from the user than the mere documentation, which requires an adequate backend and interface modeling to integrate the different settings.

There are already companies that have shown interest in such an integrative tool. One further requirement in this direction is to include the time series of evoked potential measurements, which would increase the utility of such a system in terms of knowledge discovery and documentation comprehensiveness. Including time-series data, their analyses, and their association with specific outcomes would also motivate the extension of the IOMDO ontology in terms of occurrents. Our delimitation in this work to set aside descriptions of general processes and focus on documenting events is then obsolete, and the complexity of time series should be matched with the complexity in ontological modeling before applying data mining and machine learning techniques. Of course, time-series data can also be analyzed without prior ontological annotations, and this should be done in a preliminary step. However, without ontological embedding, integration of IOM measurements from different studies and standardization of analysis result interpretations would be difficult. In other words, the advantages of semantic interoperability should be used for data analysis, leading to concepts such as ontology-based machine learning [42]. As a provider of such an all-in-one solution with an analysis component at the end of the whole IOM pipeline, an IOM medical device supplier seems promising, as it already covers many challenging parts of such a solution. Here, the main difficulty lies in translating the expertise with respect to ontologies and in the required change of the existing backend structure into an ontology-based one.

For neurophysiological and neurosurgical researchers in our setting, the requirement to consider time-related measurement data is related to many different use cases. As described above, IOM is intended to provide an early warning signal to determine when tumor tissue removal must be stopped to avoid damage to important structures such as the corticospinal tract. One important use-case for the analysis of time-series data of evoked potentials is the evaluation of such warning signals with respect to maintaining postoperative motor function. For example, Seidel et. al. analyzed a cohort of 100 patients undergoing tumor surgery with simultaneous subcortical motor mapping and DCS-MEP monitoring [43]. In a further work, they developed a new acoustic motor-evoked potential alarm as a mapping suction probe, which works like a radar on motor pathways [4, 44]. Even though some warning criteria have been identified and evaluated through such work, there is no consensus regarding the cut-off values and interpretation of MEP signal changes and alarm criteria vary among centers [3]. By creating a knowledge base for such studies conducted at many clinical centers, achieving consensus, and promoting the generation of new insights, e.g., related to repetitive signal changes before certain events, will be much easier.

We have already begun to analyze the data without embedding related annotations into our ontology, for example, by using Fourier transformation for analyzing event patterns. However, without embedding the time-series data structure into our ontology the potentials for associating different types of information and allowing in-depth interpretations are reduced. Especially for a large amount of data (about 200 MB of measurement data per surgery), knowledge representation facilitates the organization and processing of the data (storing, querying, and analyzing). If the data cannot be efficiently processed with a local computer system, the ontology should be embedded into a big data environment. There are, for example, works related to the use of the big data Hadoop framework with Apache Hive [45] or HBase [46] for storing and querying ontologies. Using and extending these works for analyzing measurement data of evoked potentials in a knowledge base should be addressed in future research.

One promise of using a top-level ontology as a basis for developing an ontology is to facilitate merging of different ontologies. In our work described here, we have indeed benefitted from integrating many BFO-based ontologies into our solution. Extending our ontology on that basis is facilitated as well. For example, our integration of OntoSPN makes it easy to include the description of surgical instruments. From the perspective of an ontology provider, we believe that other medical fields, not only surgery, can also benefit from integrating at least parts of our ontology. Especially our distinction between two ways of dealing with time-dependent data – identifying events or characterizing their processual behavior – could be helpful in providing a useful template for modeling, even if our ontology is too specific for many areas. Take, for example, the issue of categorizing epileptic seizure events in an ontology for diagnosing diseases. For the sake of mere diagnosis, it is enough to model them as information contents. However, if the goal is to better understand the disease by studying its dynamical pattern, then epilepsy should be modeled as a process. This is an issue that has been discussed in the context of using BFO for SNOMED CT [47]and our results showed that, despite the initial efforts in terms of familiarization, a BFO-based ontology is highly useful for deciding how to categorize entities.

From our work, four main central conclusions can be derived: (i) To involve the experts of the IOM subject field in the ontology development, it is crucial to provide a graphical user interface beyond Protégé. Combining JavaFX and Apache Jena proved to be highly useful for this purpose. (ii) Occurrents such as processes are mostly destined to track general dynamics, not to identify and document concrete processes related to individuals. That is the reason why events that are to be documented should be modelled as dependent continuants (information content entity) and not in terms of processes as in OAE. To further characterize these events in terms of “Diagnostic Finding” proved to be important for connecting events with other patient characteristics. (iii) Basing our ontology development on BFO facilitated the start of the ontology development. It also simplifies integration of other ontologies. For example, it was highly helpful to be able to integrate parts of domain-specific BFO-based ontologies such as OntoSPM. (iv) By creating a knowledge base for IOM, investigations on event-outcome associations, e.g., “a signal change pattern X before an event Y is causally related to the outcome Z” are enabled on a semantically enriched data base.

In summary, our study showed the usefulness of enriching ontology development with adapted software tools to ensure that medical experts can efficiently contribute to the definition of entities and the instantiation of instances. With respect our ontology design, the distinction between two ways of dealing with time-dependent data – identifying events and characterizing their processual behavior – can be helpful for many other domains. Finally, we are confident that the IOM ontology could serve as a starting point for further ontologies in neurosurgery and neurophysiology as well as for ontology-based machine learning applied to IOM signal data.

BFO

Basic Formal Ontology

DCS

Direct Cortical Stimulation

FMA

Foundation Model of Anatomy

GUI

Graphical User Interface

HPO

Human Phenotype Ontology

IAO

Information Artifact Ontology

IOM

Intraoperative Neurophysiological Monitoring

IOMDO

IOM Documentation Ontology

IRI

Internationalized Resource Identifier

MEP

Motor Evoked Potential

MIREOT

Minimum Information to Reference External Ontology Terms

MONDO

Mondo Disease Ontology

OAE

Ontology of Adverse Events

OBI

Ontology of Biomedical Investigations

OBO

Open Biological and Biomedical Ontologies

OntoSPM

Ontology for Surgical Process Models

Relation Ontology

SUS

System Usability Scale

TES

Transcranial Electrical Stimulation

Ethics approval and consent to participation

Not applicable

Consent to publication

Not applicable

Availability of data and material

Not applicable

Competing interests

The authors declare that they have no competing interests.

Funding

Not applicable

Authors' contributions

MS has worked out the design and supervised the work. PR and SN developed most of the ontology and implemented the software tool. CZ and KS contributed to the ontology as domain experts. MS, PR, and SN wrote most of the manuscript, while CZ and KS contributed to the biomedical part of the manuscript. All authors read and approved the final manuscript.

Acknowledgements

We thank Luisa Tonarelli for proodreading the manuscript and all IOM technicians (Anne Leyh, Christin Kauert, Christina Weirich-Pfaff and Sophia Birkner) for their input and participation in the software evaluation.

Seidel K, Krieg SM. Special Topic Issue: Intraoperative Neurophysiological Monitoring. J Neurol Surg Part Cent Eur Neurosurg 2021; 82: 297–298.
MacDonald DB. Overview on Criteria for MEP Monitoring. J Clin Neurophysiol Off Publ Am Electroencephalogr Soc 2017; 34: 4–11.
Asimakidou E, Abut PA, Raabe A, et al. Motor Evoked Potential Warning Criteria in Supratentorial Surgery: A Scoping Review. Cancers 2021; 13: 2803.
Raabe A, Beck J, Schucht P, et al. Continuous dynamic mapping of the corticospinal tract during surgery of motor eloquent brain tumors: evaluation of a new method. J Neurosurg 2014; 120: 1015–1024.
Abboud T, Asendorf T, Heinrich J, et al. Transcranial versus Direct Cortical Stimulation for Motor-Evoked Potentials during Resection of Supratentorial Tumors under General Anesthesia (The TRANSEKT-Trial): Study Protocol for a Randomized Controlled Trial. Biomedicines 2021; 9: 1490.
Zbinden C, Strickler M, Sariyar M, et al. Digitizing Data Management for Intraoperative Neuromonitoring. In: Röhrig R, Beißbarth T, Brannath W, et al. (eds) Studies in Health Technology and Informatics. IOS Press. Epub ahead of print 24 May 2021. DOI: 10.3233/SHTI210071.
Zbinden C, Strickler M, Sariyar M, et al. A Protocol Entry Catalog for Intraoperative Neuromonitoring – Steps Towards an Ontology. Importance Health Inform Public Health Pandemic 2020; 318–321.
Sivakumar R, Arivoli PV. Ontology Visualization Protégé Tools – a Review, https://papers.ssrn.com/abstract=3429010 (2011, accessed 17 August 2022).
Jackson RC, Balhoff JP, Douglass E, et al. ROBOT: A Tool for Automating Ontology Workflows. BMC Bioinformatics 2019; 20: 407.
Horridge M, Bechhofer S. The OWL API: A Java API for OWL ontologies. Semantic Web 2011; 2: 11–21.
Arp R, Smith B, Spear AD. Building Ontologies with Basic Formal Ontology. The MIT Press. Epub ahead of print 2015. DOI: 10.7551/mitpress/9780262527811.001.0001.
Smith B. Classifying Processes: An Essay in Applied Ontology. Ratio 2012; 25: 463–488.
Borgo S, Ferrario R, Gangemi A, et al. DOLCE: A descriptive ontology for linguistic and cognitive engineering. Appl Ontol 2022; 17: 45–69.
Miller GA. WordNet: a lexical database for English. Commun ACM 1995; 38: 39–41.
Guizzardi G, Wagner G. Using the Unified Foundational Ontology (UFO) as a Foundation for General Conceptual Modeling Languages. In: Theory and Applications of Ontology: Computer Applications. 2010, pp. 175–196.
Guizzardi G, Fonseca CM, Benevides AB, et al. Endurant Types in Ontology-Driven Conceptual Modeling: Towards OntoUML 2.0. In: Trujillo JC, Davis KC, Du X, et al. (eds) Conceptual Modeling. Cham: Springer International Publishing, 2018, pp. 136–150.
Herre H. General Formal Ontology (GFO): A Foundational Ontology for Conceptual Modelling. In: Poli R, Healy M, Kameas A (eds) Theory and Applications of Ontology: Computer Applications. Dordrecht: Springer Netherlands, pp. 297–345.
Kumar A, Smith B. The Universal Medical Language System and the Gene Ontology: Some Critical Reflections. 2003, pp. 135–148.
International Organization for Standardization. ISO/IEC 21838-2:2021. ISO, https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/07/45/74572.html (accessed 17 August 2022).
He Y, Sarntivijai S, Lin Y, et al. OAE: The Ontology of Adverse Events. J Biomed Semant 2014; 5: 29.
Jackson R, Matentzoglu N, Overton JA, et al. OBO Foundry in 2021: operationalizing open data principles to evaluate ontologies. Database 2021; 2021: baab069.
Noy NF, Mcguinness DL. Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Medical Informatics Technical Report SMI-2001-0880, Stanford, 2001.
HermiT Reasoner: Home, http://www.hermit-reasoner.com/ (accessed 1 September 2022).
Courtot M, Gibson F, Lister A, et al. MIREOT: the Minimum Information to Reference an External Ontology Term. Nat Preced 2009; 1–1.
Relation Ontology, https://obofoundry.org/ontology/ro.html (accessed 1 September 2022).
Brooke J. SUS: a retrospective. J Usability Stud 2013; 8: 29–40.
Jamal A, Tharkar S, Alenazi H, et al. Usability Analysis of a Health Sciences Digital Library by Medical Residents: Cross-sectional Survey. JMIR Form Res 2021; 5: e23293.
Gibaud B, Forestier G, Feldmann C, et al. Toward a standard ontology of surgical process models. Int J Comput Assist Radiol Surg 2018; 13: 1397–1408.
Guarino N, Welty CA. An Overview of OntoClean. In: Staab S, Studer R (eds) Handbook on Ontologies. Berlin, Heidelberg: Springer, pp. 151–171.
An Ontology for Engineering Mathematics, http://www-ksl.stanford.edu/knowledge-sharing/papers/engmath.html (accessed 1 September 2022).
Unified Code for Units of Measure (UCUM) at NLM, https://ucum.nlm.nih.gov/ (accessed 1 September 2022).
Berrueta D, Polo L, Álvarez J. Measurement units ontology. Measurement units ontology, https://databus.dbpedia.org/ontologies/elite.polito.it/ontologies--muo-vocab--owl (2008, accessed 1 September 2022).
Keil JM, Schindler S. Comparison and evaluation of ontologies for units of measurement. Semantic Web 2019; 10: 33–51.
Rijgersberg H, van Assem M, Top J. Ontology of units of measure and related concepts. Semantic Web 2013; 4: 3–13.
Yu H, Nysak S, Garg N, et al. ODAE: Ontology-based systematic representation and analysis of drug adverse events and its usage in study of adverse events given different patient age and disease conditions. BMC Bioinformatics 2019; 20: 199.
Marcos E, Zhao B, He Y. The Ontology of Vaccine Adverse Events (OVAE) and its usage in representing and analyzing adverse events associated with US-licensed human vaccines. J Biomed Semant 2013; 4: 40.
Guo A, Racz R, Hur J, et al. Ontology-based collection, representation and analysis of drug-associated neuropathy adverse events. J Biomed Semant 2016; 7: 29.
Wang L, Li M, Xie J, et al. Ontology-based systematical representation and drug class effect analysis of package insert-reported adverse events associated with cardiovascular drugs used in China. Sci Rep 2017; 7: 13819.
Gong Y, Zhu M, Li J, et al. Clinical communication ontology for medical errors. Stud Health Technol Inform 2007; 129: 1007–1011.
Henegar C, Bousquet C, Lillo-Le Louët A, et al. Building an ontology of adverse drug reactions for automated signal generation in pharmacovigilance. Comput Biol Med 2006; 36: 748–767.
Adam TJ, Wang J. Adverse Drug Event Ontology: Gap Analysis for Clinical Surveillance Application. AMIA Jt Summits Transl Sci Proc AMIA Jt Summits Transl Sci 2015; 2015: 16–20.
Kulmanov M, Smaili FZ, Gao X, et al. Semantic similarity and machine learning with ontologies. Brief Bioinform 2021; 22: bbaa199.
Seidel K, Beck J, Stieglitz L, et al. The warning-sign hierarchy between quantitative subcortical motor mapping and continuous motor evoked potential monitoring during resection of supratentorial brain tumors. J Neurosurg 2013; 118: 287–296.
Raabe A, Beck J, Schucht P, et al. Continuous dynamic mapping of the corticospinal tract during surgery of motor eloquent brain tumors: evaluation of a new method: Clinical article. J Neurosurg 2014; 120: 1015–1024.
Karim N, Latif K, Anwar Z, et al. Storage schema and ontology-independent SPARQL to HiveQL translation. J Supercomput 2015; 71: 2694–2719.
Wang H, Sun K, Wang X. A query method for domain ontology based on HBase. In: 2017 13th International Conference on Natural Computation, Fuzzy Systems and Knowledge Discovery (ICNC-FSKD). 2017, pp. 1735–1740.
Hogan W. Aligning the top-level of SNOMED-CT with Basic Formal Ontology. Nat Preced 2008; 1–1.

No competing interests reported.

Download PDF

Version 1

posted

You are reading this latest preprint version

Ontology and tool development for documenting intraoperative monitoring in neurosurgery

Status:

Version 1

Abstract

Figures

1 Introduction

2 Methods

2.1 Ontology development

2.2 Software development

2.3 Software evaluation

3 Results

3.1 The IOMDO ontology

3.2 The IOMDO-based software

3.3 Software evaluation

4 Discussion

5 Conclusions

Abbreviations

Declarations

References

Additional Declarations

Status:

Version 1