Bernard Gibaud Equipe MediCIS, LTSI INSERM 1099, Rennes, France OntoSPM, a core ontology for surgical process models: motivations, working assumptions and current status Bernard Gibaud Equipe MediCIS, LTSI INSERM 1099, Rennes, France

Contributors Bernard Gibaud Pierre Louis Hénaux Pierre Jannin Darko Katic Cédric Pénet Javier Rojas Balderrama

Overview Context and motivations Methodology Basic assumptions Current status Discussion Conclusion

Context and Motivations

S3PM project Creation of simulation scenari for the training of scrub nurses using Virtual Reality Need for representing situations that are both various and realistic Approach: learn from real procedures Consequence: need to have a language to describe surgical processes Used to annotate video recordings

S3PM project’s framework Recording of actual surgical procedures Proc instances Ontology Validation/editing Generation of model (using Test&Flip algo ) Procedure model Validation/editing Generation and exec of procedure scenari scenari Validation/editing

Ontology development S3PM-related goal OntoSPM-related goal to create a common ontology to meet the S3PM project’s requirements OntoSPM-related goal To create a core ontology of surgical procedures, suitable for S3PM as well as other projects

… Modularity ONTOSPM (generic) Human Instrument Body part Action Role Application 1 Instrument Body part Action Role Application n Instrument Body part Action Role …

OntoSPM: Motivations Why an open core ontology of SPM ? To facilitate the work of those who need ontologies of SPM To encourage the creation of a standard for surgical procedure description Suitable for various applications (context-aware systems, simulation, skills assessment, etc.) To facilitate the interoperability of data repositories and software in surgical data science

Methodology: General framework Intended usage, users Competency questions Relevant ontologies Significant entities Terminology Overall structure Foundational ontology Organization in modules « Towards Ontology Evaluation across the Life Cycle », by Fabian Neuhaus and Amanda Vizedom, Ontology Summit 2013

Basic assumptions

Basic assumptions: Open and free Fees are a barrier to adoption Relevant existing ontological resources are free of charge and open Remark : not all are …, e.g. SNOMED CT

Basic assumptions: Built from existing ontological resources Examples of relevant ontologies Information Artifacts Ontology (IAO) Ontology of Biomedical Investigation (OBI) Foundation Model of Anatomy (FMA) Pathology (MPATH)

Basic assumptions: Rely on a consistent integration framework Based on an upper level ontology (e.g. BFO, DOLCE, SUMO, OpenCyc), providing a basic modeling framework and axiomatization a set of basic entities and relationships Used by the other ontology modules (ideal case) e.g. OBI/IAO and BFO

OntoSPM: Current status

Current status Language of representation Choice of an upper level ontology Modular structure and extraction of modules Entity naming conventions Domain currently covered

Language of representation OWL DL Ontology (Description Logics formalism) TBox : ‘terminological’ component Defines classes and properties Specifies axioms (assumed true for any instance) e.g. Action subClassOf Process « all Actions are Processes » ABox : ’assertional’ component Concerns individuals (instances) and their relationships e.g. « thisaction isA Action »

Choice of an upper level ontology Choice: Basic Formal Ontology (BFO2 + RO) Why ? Used by many ontology development groups in life science Based on OBO Foundry principles Reasonably well documented

Basic Formal Ontology 2

Main basic object properties Selected from BFO/RO continuantPartOf (inverse : hasContinuantPart) Domain: continuant Range: continuant occurrentPartOf (inverse : hasOccurrentPart) Domain: occurrent Range: occurrent inheresIn (inverse : bears) Domain: ‘dependent continuant’ Range: continuant realizes (inverse : realizedIn) Domain: occurrent Range: function or role participatesIn (inverse : hasParticipant) Domain: - Range: - Selected from IAO (Information Artifact Ontology) isAbout Domain: ‘generically dependent continuant’ Range: -

Modular structure OntoSPM.owl imports five ontology modules BFO.owl IAO_for_ontoSPM.owl FMA_for_ontoSPM.owl MPATH_for_ontoSPM.owl PATO_for_ontoSPM.owl UO_for_ontoSPM.owl Simple Knowledge Organization System (skos) Upper level entities Information content entities Anatomical entities Pathological entities Phenotypic qualities Units of measure Annotations

Extraction of terms from external ontologies Extract corresponding entities using OntoFox* Allows specifying various options, e.g. : whether all child terms should be retrieved (includeAllChildren) whether all intermediate terms should be retrieved up to a top level source term (includeAllIntermediates) In practice 1. We create a list of terms (excel sheet) 2. Create an OntoFox extraction file (by program) 3. Get the ontology module and import it in OntoSPM * Xiang Z, Courtot M, Brinkman RR, Ruttenberg A, He Y. OntoFox: web-based support for ontology reuse. BMC Research Notes. 2010, 3:175.

Naming conventions For entities borrowed from existing ontologies In general, we kept existing IRIs, as well as existing annotations (e.g. rdfs:label, rdfs:prefLabel) For new OntoSPM entities We assigned new IRIs (based on english labels) As well as rdfs:prefLabel in english, french and german

Domain currently covered Surgical processes modeled as bfo:process For example: the surgical procedure and action classes Both model real-life processes, i.e. processes that have occurred in reality Emphasis was primarily put on actions, and on the entities participating in the actions, each mode of participation being modeled using roles (bfo:role)

Modeling of roles Distinguishing between several participation roles ‘affected physical object’ ‘human actor’ (inheresIn some human) ‘human effector’ (inheresIn some ‘body part’) ‘instrument effector’ ‘interaction role’ (inheresIn some (‘human’ or ‘medical device’)) ‘input data’ ‘output data’

Modeling of actions Various kinds of actions, e.g. ‘human action’ hasAgent some human ‘medical device action’ hasAgent some ‘medical equipment’ Relation with participating roles, e.g. ‘human action’ realizes some ‘human actor’ (e.g. ‘scrub nurse’) ‘human action’ realizes some ‘human effector’ (e.g. ‘right hand’) Definition of interaction actions ‘human interaction’, such as ‘language act’ (e.g. informing) realizes some ‘interaction initiator’ realizes some ‘interaction destination’

Modeling of surgical instruments and materials Classification of ‘surgical instrument’ based on their function, e.g. ‘clipping instrument’ hasInstrumentFunction some 'to clip’ ‘dissecting instrument’ hasInstrumentFunction some 'to dissect’ ‘instrument container’ hasInstrumentFunction some 'to contain’ ‘surgical material’ e.g. cannula, cup, drape, compress, cotonoid, needle, thread, ‘surgical glove’, etc.

Domain currently covered Surgical processes models Several granularity levels ‘surgical procedure’ ‘surgical phase’ ‘surgical step’ Action However, so far, no formal criteria to categorize some process as a ‘surgical phase’ or ‘surgical step’

Time-related entities (borrowed from W3C time ontology) ‘temporal interval’ and ‘proper interval’ subClassOf bfo:’one dimensional temporal region’ One can associate to it some ‘duration description’, thanks to the hasDurationDescription object property Axioms allowing to associate values

Time-related entities (borrowed from W3C time ontology) ‘temporal instant’ subClassOf bfo:’zero dimensional temporal region’ One can associate to it some value thanks to the inXSDdateTime data property

Time-related entities (borrowed from W3C time ontology) intervalBefore (inverse: intervalAfter) intervalContains (inverse: intervalDuring) intervalFinishes (inverse: intervalFinishedBy) intervalMeets (inverse: intervalMetBy) intervalOverlaps (inverse: intervalOverlappedBy) intervalStarts (inverse: intervalStartedBy) intervalEquals A B A B A B A B A B A B

Discussion

Discussion: How to enrich the core ontology ? S3PM ontology OntoSPM ontology

Discussion: BFO2 BFO 2: Quite comprehensive Not always intuitive Use of IRIs such as BFO_0000040 Quite complex axiomatization RO not integrated in BFO2, yet Some ontologies still use BFO 1.1

Discussion: external ontologies Anatomy (FMA), Pathology (MPATH) It is hard to define what subset is relevant SNOMED CT Not used (because not open, nor free of charge) France and Germany not member of IHTSDO

Discussion: ‘procedure plans’ Many applications need to reason about processes that might happen in the future Define relationships between them (partOf, precedes/follows, etc.) According to BFO, such entities should not be considered as bfo:process, but rather as bfo:plan, e.g. ‘procedure plan’, that may be described in obi:’plan specification’ may be realized as bfo:’planned process’

Conclusion A first version of OntoSPM exists From this starting point not broadly distributed, yet currently in use in limited applications S3PM project (MediCIS, Rennes) Surge Track software (b<>com, Rennes) LapOntoSPM (KIT, Karlsruhe) From this starting point Setup a collaboration to create an extended version This workshop is aimed at exploring how such collaboration should be setup

Thank you for your attention

Ontology-based annotation of surgical processes Label ‘xx’ ‘yy’ ‘zz’ IRI <http://…> <http://…> <http://…> Selected vocabulary Selection of terms SPARQL Query OntoSPM IRI _xx01 _xx02 _xx03 <http://…> <http://…> <http://…> Prop IRIs isA relx rely relz _yy01 _yy02 _yy03 RDF annotation data Application ontology Annotation process Live procedure or video record e. g. Surge Track User input Implementation as SPARQL endpoint SPARQL Query