=Paper= {{Paper |id=Vol-2849/paper-02 |storemode=property |title=None |pdfUrl=https://ceur-ws.org/Vol-2849/paper-02.pdf |volume=Vol-2849 |dblpUrl=https://dblp.org/rec/conf/swat4ls/SlaughterH19 }} ==None== https://ceur-ws.org/Vol-2849/paper-02.pdf

Suggesting Reasonable Phenotypes to Clinicians

Laura Slaughter and Dag Hovland[0000−0002−3569−8838]

Dept. of Informatics, University of Oslo, Norway
{laurasla,hovland}@ifi.uio.no

Abstract. We describe a method for aiding clinicians in the process of
reporting clinical features (abnormalities and symptoms) in newborns
with suspected rare genetic diseases. The Human Phenotype Ontology
(HPO) is well suited for such characterization, but impractical to navi-
gate in a clinical situation. We enable different entry points depending on
clinical specialization, detect certain types of errors that may occur, and
suggest related phenotypes and candidate diseases to check for further
clinical workup. Our main improvements are: (1) incompatible entries
are highlighted and/or denied; (2) relevant related phenotypes are sug-
gested; and (3) diseases are proposed in cases where the clinical report
contains a complete profile and includes highly specific phenotypes.

Keywords: Human Phenotype Ontology · Reasoner · Rare Diseases

1 Introduction

The process of differential diagnosis is a systematic method used by clinicians to
eliminate disease candidates, narrowing the possibilities, until the correct diag-
nosis is made. In rare disease diagnostics of newborns, this process can take years
and involves genetic sequencing. Correct diagnosis can be a lengthy process that
involves an entire healthcare team, including clinicians who communicate ob-
servations of abnormalities and geneticists who search within the gene sequence
for variants, leading to a molecular diagnosis. It is an iterative process, and in
newborns can be challenging, since some abnormalities will not manifest until
specific developmental stages [11].
It is important to make a conclusive diagnosis for newborns as quickly as pos-
sible so that treatment can begin and it is known whether or not the condition
is immediately life-threatening. It is also helpful for the parents to have less un-
certainty surrounding the needs of the child. Having a full picture of symptoms,
signs, family history and other clinical features is essential to the geneticists
who need to narrow down the possibilities and match clinical features to specific
genetic variants.
Tools for helping clinicians specify and communicate clinical features have
been developed to be used within the differential diagnostic process. These tools
are based on use of the Human Phenotype Ontology (HPO), a standardized
vocabulary of phenotypic abnormalities structured as a directed acyclic graph

Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
2 Laura Slaughter and Dag Hovland

(DAG). Each term in the HPO describes a phenotypic abnormality, such as
”Atrial septal defect” and terms can have parent terms, in the case of ”Atrial
septal defect”, its parent is ”Abnormal atrial septum morphology” and it is also
the parent of several more specific child terms, including ”Secundum atrial septal
defect” and ”Unroofed coronary sinus”.
In addition to openly available entry tools using HPO codes, some hospitals
may have other means for specifying clinical features and communicating these
to geneticists. In our case, hospitals have implemented the use of a genetic testing
requisition form within the Electronic Health Records (EHR) containing a list
of phenotypical abnormalities, organized in categories related to bodily systems,
anatomy or processes (e.g. neurological, developmental, muscle/skeletal) [6]. The
observations are conveyed to the geneticist when the clinician requests genetic
testing by checking off terms on the requisition form.
There are both legal and design-related issues associated with implementing
the openly available existing tools for specifying clinical features of patients. In
addition, the hospital requisition form is an inadequate means to communicate
needed information with the geneticist. Problems observed when using existing
open source HPO-related phenotyping tools include: (1) an overwhelming set of
HPO codes to select in the user interface, allowing inconsistency in responses; (2)
unclear meaning behind a ”no” response for a term, and (3) limited prompts or
suggestions for further patient workup. The requistion form, while more simplis-
tic contains too few clinical feature observational terms, is not well-connected to
HPO which has become a standard tool for geneticists, and provides no feedback
whatsoever to the clinician.
Our aim is therefore to improve the specificity of the clinical features commu-
nicated to the geneticist by providing suggestions to clinicians to reduce incon-
sistencies, prompt for potentially missed observations, and help with deciding
on further needed workup (e.g. additional lab tests, imaging). We developed a
proof-of-concept web application1 addressing these goals. The application uses
semantic technology to leverage the HPO DAG and parent-child hierarchical
structures. We use HPO, biomedical ontologies, and other knowledge resources
to provide additional information to clinicians that increases the quality of infor-
mation communicated further to the geneticist and helps with speeding up the
diagnostic process in newborns. In this work, we address both the 1) suggestion
service and 2) user ”information interaction” issues that are connected to the
user interface.

2 Related Work
Supporting the process of teamwork in the diagnostic process is a challenge [2].
The geneticist relies on the clinician to gather as much information as possible
during clinical observations in order to inform the task of searching the genetic
sequence for variants. These are used to search databases containing clinical
features-disease associations.
1
Available at https://gitlab.com/hovlanddag/rekvisisjon
Suggesting Reasonable Phenotypes to Clinicians 3

Phenotips [3], has been developed for gathering a complete picture of the
patient’s clinical features (i.e. phenotype), including demographics, medical his-
tory, family history, physical and laboratory measurements, and physical find-
ings. Phenotips uses a form-based data entry mechanism and the UI is said
to closely mirror the clinician workflow. Phenotips allows for predictive search,
when the user enters a term, it works to correct misspellings and suggests terms
according to semantic relations. The tool provides some feedback to the user on
the completeness of the phenotype, through ”star ratings” which is a ”sufficiency
rating”. They state that the goal is to make a profile ”specific enough to exclude
similar diseases and to identify model organisms with similar phenotypes that
may have mutations in relevant genes or pathways.” The ”star rating” is, in
some ways, a type of suggestion.
The user interface (UI) for Phenotips allows the clinician to select various
HPO codes and also specify ”NA/Yes/No”. The forms used are not ontology-
driven and do not make use of the HPO hierarchy. One could assume that if a
patient showed ”cachexia” and the clinician selected ”yes” indicating presence,
then it would be an inconsistent selection if the clinician also selected ”no” to its
parent term ”weight loss”. If a patient has ”cachexia” which is defined as severe
weight loss, then it would be inconsistent to also say that the patient does not
have ”weight loss”. However, the Phenotips UI does not provide feedback to
the clinician when such inconsistencies occur. Phenotips has opted for entering
the upper navigable layer of HPO into the code. There may of course be good
performance reasons for this, but this made it impossible to experiment with
leveraging a reasoner to improve the HPO entry process live.
Another tool is Phenotero, an annotation tool that adds HPO codes +
MONDO (Monarch Initiative Disease Ontology) to clinical notes as the user
writes [5]. Phenotero is an extension of the Zotero tool, a citation management
software, and is also available for use within Google Docs, LibreOffice, and Mi-
crosoft Word. The user writes clinical text and then manually adds a ”citation”,
which is the HPO code, with the help of lexical matching search. Phenotero does
not provide any completeness of phenotype, no analysis of the annotated coding,
and no suggestions for related phenotypes.
Natural language entry tools also have been developed to help the clinician
identify relevant HPO codes. The doc2HPO tool automatically recognizes HPO
codes in clinical notes [8]. The tool allows the user to choose between different
parsing engines, extracting concepts from the text and mapping to HPO codes.
The system makes use of the Unified Medical Language System (UMLS) to map
between identified UMLS concepts and HPO codes. The system is an HPO code
curation/entry system and does not help clinicians with the process of deciding
on possible further work-up or listing possible disease candidates.
Text mining tools such as NCBO Annotator+ [10] also can be used to an-
notate clinical texts for HPO codes, but there are known performance issues.
There are problems with disambiguation of annotations (too many polysemic
terms decrease precision) and for clinical text mainly, cleaning and reformatting
of the text (abbreviations, spelling mistakes, unconventional sentence structures,
4 Laura Slaughter and Dag Hovland

decrease recall). The Phenomizer [7] is a tool that is focused on differential diag-
nosis. The resulting output from the tool is a ranked list of diagnoses, however, it
does also generate some related HPO codes (clinical features) to be considered
for further work-up. These suggestions are not the main purpose of the tool,
however, and are not well-displayed or considered within the user interface.

3 Suggestions

Our main goal is to suggest HPO codes, diseases and subsequent further patient
work-up to improve the quality of the clinical profile provided to the geneticists.
This has a dual purpose. The clinician becomes aware of HPO codes that are
informative for geneticists and is able to provide a more complete picture of
the patient. In addition, the second purpose is to motivate clinician-geneticist
communication where both participate in the diagnostic process as a team. The
completeness of the clinical profile of the patient is essential for a molecular
diagnosis. The ability to diagnose rare monogenetic diseases through identifi-
cation of gene variants requires this communication of phenotypes and patient
characteristics with the cooperation of the clinician.
We provide suggested diseases and HPO codes to clinicians based on a simple
lookup mechanism with information about disease-HPO code associations. These
are found in the HPO ontology annotation file2 . However, even a few HPO
terms (phenotype codes) may lead to a long list of potential disease candidates
and therefore gene variant candidates become too numerous. An ordering or
prioritization is necessary. Because we are constructing a tool that will aid the
clinician in diagnostic work, suggestions come in the form of HPO codes that
point to further workup needed in the diagnostic process. The tool does not
function as a differential diagnosis ”clinician-replacement” machine. Rather we
aim at suggesting diseases that are very specific and/or rare, thus augmenting the
knowledge of the trained professional clinician. We also use disease information
to inform HPO code priority and ordering. We aim for measuring the specificity
of the disease given the currently entered phenotype. We measure the specificity
by percent coverage: Let X be the set of phenotypes (HPO Codes) which are
given a ”Yes” click. For a disease i, let Φi be the set of phenotypes linked to it by
the annotation files. The specificity of disease i is then |Φi ∩ X|/|X|, a number
from 0 to 1, with 1 meaning that all features are present in the patient, and 0
no features present.
Unfortunately, this ordering gives a bias to diseases with few registered fea-
tures, especially as the first few entries are made. Therefore, other heuristics are
needed to order the many entries with a specificity of 1. We order entries (with
the same specificity) in decreasing order of the number of patient features that
are not registered on the disease. That is, by |X − Φi |. This order works only if
these assumptions are correct:

– All entered features are pathologic, in the sense that a diagnosis is wanted
2
https://hpo.jax.org/app/download/annotation
Suggesting Reasonable Phenotypes to Clinicians 5

– All the features stem from the same disease

This is clearly not the case in a general patient population, but in newborn
patients with genetic disease, it is unlikely that two such diseases should occur.
Also, newborns do not have the accumulated damage and injury that occur over
a lifetime and may lead to other pathological features.
We plan to allow for additional orderings that the user can control. Another
ordering that can be selected is:

– |Φi ∩ X|. That is, by how many disease-relevant features are seen in the
patient. The problem with this ordering is that diseases with many linked
features may be given unreasonably high priority.

3.1 Phenotype Suggestions

We use the ready-made entries, together with the annotation files and ontolo-
gies, to suggest phenotypes the clinician should look for, especially HPO phe-
notypes that might exclude certain diseases. For phenotype suggestions, we use
the existing phenotype selection interface to signal suggested phenotypes. If the
phenotype in question is already visible, we highlight it, otherwise we highlight
the most specific superclass which is visible. We also show (an excerpt of) the
list of diseases which would be more likely if that phenotype is present.
The prioritization of suggested phenotypes is not directly visible, as the out-
put is not ordered. However, a heuristic for which phenotypes to show is im-
portant. We order diseases, in increasing order, by the ratio of not selected
phenotypes:
ρi = |Φi − X|/|Φi |
We are experimenting with different cutoff values, ρmax , for ρ. For all diseases
i with a ρi < ρmax , we display/suggest the phenotypes Φi − X. Too high ρmax
risk giving the clinician a bias too early. Too low will only give feedback in very
specific cases.
It is not a problem to display any number of phenotype suggestions, as the
interface only shows the uppermost classes. However, the usefulness of the feed-
back is decreased if a few low-ρ diseases drown in a large number of diseases
with higher ρ. Therefore we only show phenotypes from those diseases with the
lowest ρ, but always at least nmin suggestions.
To summarize, the algorithm is to suggest the phenotypes Φi − X if
[
ρi < ρmax or | Φk − X| < nmin (1)
k,ρk <ρi

The most useful values of ρmax and nmin needs further work. However, we expect
they will depend on the clinical setting and experience with the interface, and
may need to be configurable. In our initial experiments, we have used ρmax = 0, 2
and nmin = 10.
6 Laura Slaughter and Dag Hovland

3.2 User Interface

We provide help for customizing the UI for use in newborn diagnostics and
the ontology provides the basis for prompting consistency in reporting. Sim-
ilarly, other biomedical semantic technology projects have used ontologies to
drive form-based data acquisition [4] [9].
The HPO phenotypes are provided as part of a form, with checkboxes to
provide relevant information for the geneticist. By expanding the main header
from the Norwegian requistion form, a list of phenotypes for that category is
shown, with a selection for ”Yes”, ”No”, or ”?”. We added a new checkbox to
distinguish between ”No” and ”?”. Whenever ”Yes” is ticked on a box, the direct
subclasses in HPO is shown below. When the clinician checks No, a dropdown
list of reasons is shown:

– Examined patient, not present
– Age of onset not reached
– Manifestation unrealizable
– Unable to examine patient

The three last items merit some explanation. Some symptoms can only
present at certain ages. Especially newborns may often be lacking phenotypes
that are only manifested after a certain age (e.g. developmental delays and cogni-
tive impairment). Other phenotypes may be impossible in a patient, e.g. if organs
are missing. Finally, in some patients, conducting tests to determine presence of
an abnormality might be too invasive or otherwise high risk to the patient.

Fig. 1. Detail from the user interface showing a patient with cutaneous melanoma.

Note that in the existing requisition form implemented in our hospital, with
only a box to check, the lack of a check could mean any of the reasons listed,
in addition to ”Not checked”, which is indicated by the ”?” in our form. In the
case that the clinician provides some reason, this may speed up the communica-
tion between geneticist and clinician. There is, for example, no need to ask for
clarification of a phenotype which cannot possibly be present at the current age
or state of the patient.
Secondly, whenever ”No” is clicked, the tool runs a background check for
consistency. That is, to see if there any clicks of ”Yes” on the same phenotype,
or specializations of it. This kind of inconsistency can happen because the HPO
Suggesting Reasonable Phenotypes to Clinicians 7

is not a tree, that is, it is possible to navigate to the same phenotype from
different top-level entries. We anticipate that the most useful part of this feature
is during cooperation. Over time, several clinicians will be working with the same
patient, and the perception of the phenotype will change. Interactive feedback
about conflicting entries may lead to earlier detection of conflicting views about
the patient, such that measures to resolve this can be taken as early as possible.

4 Technical Implementation

Since we expect interactive answers using reasoning on a quite large ontology,
it is important with an efficient ontology storage solution. For storing the HPO
ontology we tried many different libraries, and the architecture allows switching
between different stores. Since this is a technology in development we anticipate
switching triple stores. The ontology can either be accessed directly by the ap-
plication, or be accessed externally in a separate store. For the internal store we
tried the Jena in-memory model, TDB, RDFOx and Sequoia. For external access
we used a Fuseki triple store and tried with TDB and some others. Currently our
application is using Sequoia in-memory (not externally). [1]. This is partially for
simplicity, and we expect that in a production environment, having the ontology
in an external triple store will be more maintainable. Sequoia is a quite new
reasoner developed in Oxford, and supports only a subset of axioms and queries,
but enough for HPO, as it mainly uses subclass axioms. The questions we ask
are about navigation in this hierarchy: What are the super- and or subclasses of
a given class.
The following artifacts are parsed and loaded: (1) HPO Ontology; (2) list of
HPO entries shown as entry point of navigation (e.g. corresponding to current
checkboxes in the requisition form); and (3) annotation files from HPO. These
are tab-separated files where each line links a single HPO entry to entries in
other ontologies. Some files link to diseases (OMIM, Orphanet and DECIPHER)
and other files link to genes. The application must also maintain the current
phenotype of the patient. One part of this is to maintain the boxes that are
clicked Yes or No. This we currently do in a simple map. It could also be stored
as data properties in a triple store that imports the HPO Ontology. The question
of consistency could then be answered by a simple query to the triple store.
However, none of the triple stores we tried could both store this information and
answer the question fast enough, so we currently store the phenotype in-memory
as a map and handle the consistency by asking several super- and subclass queries
to the ontology and checking for errors. Although not ideal, as functionality that
certainly exists in imported libraries is replicated, it is faster and also allows
easily obtaining the reasons for inconsistency. The user interface is written in
javascript and runs on the web browser. It uses REST calls to connect to the
server part, which runs in a web container. All reasoning currently happens in
the server. Our phenotyping tool is available 3 under an open source license.
3
From https://gitlab.com/hovlanddag/rekvisisjon
8 Laura Slaughter and Dag Hovland

5 Conclusion and Future Work

The project of replacing the Norwegian requisition form led to the need for high
flexibility in the setup of the user interface, and we were unable to make use
of existing tools such as Phenotips. We have applied existing semantic tech-
nologies (Sequoia, HPO ontology) and demonstrated how these can be used to
quickly navigate large knowledge sources. We have also applied the use of se-
mantic technology to the task of creating suggestions for pediatricians using the
HPO ontology, including different types of heuristics for giving feedback to the
pediatrician during data entry time. We implemented mechanisms for avoiding
inconsistent entries in reporting clinical features. In conclusion, we use several
techniques to suggest HPO codes to pediatricians to improve their ability to
provide as much useful information in reporting the patient’s clinical character-
istics to the geneticists. The next step is to validate the software with formal
user testing, including iterative usability testing with pediatricians.

6 Acknowledgements

This work was done as part of the BIGMED project, funded by the Norwe-
gian Research Council, Project No. 259055. We would like to thank the project
members, and especially Yngve Sejersted and Tony Håndstad at Oslo University
Hospital for invaluable input on rare diseases and genetic testing.

References
1. Bate, A., Motik, B., Grau, B.C., Simancik, F., Horrocks, I.: Extend-
ing consequence-based reasoning to SRIQ. In: Baral, C., Delgrande, J.P.,
Wolter, F. (eds.) Principles of Knowledge Representation and Reason-
ing: Proceedings of the Fifteenth International Conference, KR 2016, Cape
Town, South Africa, April 25-29, 2016. pp. 187–196. AAAI Press (2016),
http://www.aaai.org/ocs/index.php/KR/KR16/paper/view/12882
2. Baynam, G., Walters, M., Claes, P., Kung, S., LeSouef, P., Dawkins, H., Bellgard,
M., Girdea, M., Brudno, M., Robinson, P., et al.: Phenotyping: targeting genotype’s
rich cousin for diagnosis. Journal of paediatrics and child health 51(4), 381–386
(2015)
3. Girdea, M., Dumitriu, S., Fiume, M., Bowdin, S., Boycott, K.M., Chénier, S.,
Chitayat, D., Faghfoury, H., Meyn, M.S., Ray, P.N., et al.: P heno t ips: Patient
phenotyping software for clinical and research use. Human mutation 34(8), 1057–
1065 (2013)
4. Gonçalves, R.S., Tu, S.W., Nyulas, C.I., Tierney, M.J., Musen, M.A.: An ontology-
driven tool for structured data acquisition using web forms. Journal of biomedical
semantics 8(1), 26 (2017)
5. Hombach, D., Schwarz, J.M., Knierim, E., Schuelke, M., Seelow, D., Köhler, S.:
Phenotero: Annotate as you write. Clinical genetics 95(2), 287–292 (2019)
6. Jiménez-Ruiz, E., Hovland, D., Slaughter, L., Håndstad, T., Waaler, A.: On im-
proving the phenotype acquisition process using semantic web technology. In:
Suggesting Reasonable Phenotypes to Clinicians 9

Paschke, A., Burger, A., Splendiani, A., Marshall, M.S., Romano, P., Presutti,
V. (eds.) Proceedings of the 10th International Conference on Semantic Web Ap-
plications and Tools for Health Care and Life Sciences (SWAT4LS 2017), Rome,
Italy, December 4-7, 2017. CEUR Workshop Proceedings, vol. 2042. CEUR-WS.org
(2017), http://ceur-ws.org/Vol-2042/paper9.pdf
7. Köhler, S., Schulz, M.H., Krawitz, P., Bauer, S., Dölken, S., Ott, C.E., Mundlos,
C., Horn, D., Mundlos, S., Robinson, P.N.: Clinical diagnostics in human genetics
with semantic similarity searches in ontologies. The American Journal of Human
Genetics 85(4), 457–464 (2009)
8. Liu, C., Kury, P., Sampaio, F., Li, Z., Ta, C., Wang, K., Weng, C.: Doc2hpo: a web
application for efficient and accurate hpo concept curation. Nucleic acids research
(2019)
9. Stenzhorn, H., Weiler, G., Brochhausen, M., Schera, F., Kritsotakis, V., Tsiknakis,
M., Kiefer, S., Graf, N.M.: The obtima system-ontology-based managing of clinical
trials. In: Medinfo. pp. 1090–1094 (2010)
10. Tchechmedjiev, A., Abdaoui, A., Emonet, V., Melzi, S., Jonnagaddala, J., Jonquet,
C.: Enhanced functionalities for annotating and indexing clinical text with the ncbo
annotator+. Bioinformatics 34(11), 1962–1965 (2018)
11. Wright, C.F., FitzPatrick, D.R., Firth, H.V.: Paediatric genomics: diagnosing rare
disease in children. Nature Reviews Genetics 19(5), 253 (2018)