1. 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

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

3. Overview Context and motivations Methodology Basic assumptions
Current status
Discussion
Conclusion

4. Context and Motivations

5. 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

6. 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

7. 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

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

9. 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

10. 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

11. Basic assumptions

12. 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

13. 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)

14. 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

15. OntoSPM: Current status

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

17. 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 »

18. 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

19. Basic Formal Ontology 2

20. 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: -

21. 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

22. 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.

23. 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

24. 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)

25. 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’

26. 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’

27. 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.

28. 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’

29. 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

30. 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

31. 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

32. Discussion

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

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

35. 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

36. 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’

37. 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

38. Thank you for your attention

39. Ontology-based annotation of surgical processes
Label
‘xx’
‘yy’
‘zz’
IRI
< <
<
Selected
vocabulary
Selection
of terms
SPARQL
Query
OntoSPM
IRI
_xx01
_xx02
_xx03
< <
<
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