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 navigate in a clinical situation. We enable di erent 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 suggested; and (3) diseases are proposed in cases where the clinical report contains a complete pro le and includes highly speci c phenotypes.
The process of di erential diagnosis is a systematic method used by clinicians to
eliminate disease candidates, narrowing the possibilities, until the correct
diagnosis 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
observations 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
speci c developmental stages [
It is important to make a conclusive diagnosis for newborns as quickly as possible 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 uncertainty 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 speci c genetic variants.
Tools for helping clinicians specify and communicate clinical features have been developed to be used within the di erential 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). (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 speci c 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) [
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 simplistic 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 speci city of the clinical features communicated to the geneticist by providing suggestions to clinicians to reduce inconsistencies, 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 information 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
Supporting the process of teamwork in the diagnostic process is a challenge [
Phenotips [
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 ontologydriven 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 de ned 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 [
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 [
Text mining tools such as NCBO Annotator+ [
Our main goal is to suggest HPO codes, diseases and subsequent further patient work-up to improve the quality of the clinical pro le 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 pro le of the patient is essential for a molecular diagnosis. The ability to diagnose rare monogenetic diseases through identi 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 le2. 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 di erential diagnosis "clinician-replacement" machine. Rather we aim at suggesting diseases that are very speci c 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 speci city of the disease given the currently entered phenotype. We measure the speci city 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 les. The speci city of disease i is then j i \ Xj=jXj, 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 features, especially as the rst few entries are made. Therefore, other heuristics are needed to order the many entries with a speci city of 1. We order entries (with the same speci city) in decreasing order of the number of patient features that are not registered on the disease. That is, by jX ij. This order works only if these assumptions are correct: { All entered features are pathologic, in the sense that a diagnosis is wanted
{ 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: { j i \ Xj. 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 les and ontologies, to suggest phenotypes the clinician should look for, especially HPO phenotypes 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 speci c 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 output is not ordered. However, a heuristic for which phenotypes to show is important. We order diseases, in increasing order, by the ratio of not selected phenotypes: i = j i
Xj=j ij We are experimenting with di erent cuto 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 speci c 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 feedback 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 j
[ k; k< i k
Xj < nmin
(1)
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 con gurable. In our initial experiments, we have used max = 0; 2
and nmin = 10.
We provide help for customizing the UI for use in newborn diagnostics and
the ontology provides the basis for prompting consistency in reporting.
Similarly, other biomedical semantic technology projects have used ontologies to
drive form-based data acquisition [
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 cognitive 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.
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 communication between geneticist and clinician. There is, for example, no need to ask for clari cation 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 is not a tree, that is, it is possible to navigate to the same phenotype from di erent 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 con icting entries may lead to earlier detection of con icting views about the patient, such that measures to resolve this can be taken as early as possible. 4
Since we expect interactive answers using reasoning on a quite large ontology,
it is important with an e cient ontology storage solution. For storing the HPO
ontology we tried many di erent libraries, and the architecture allows switching
between di erent stores. Since this is a technology in development we anticipate
switching triple stores. The ontology can either be accessed directly by the
application, 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). [
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 les from HPO. These are tab-separated les where each line links a single HPO entry to entries in other ontologies. Some les link to diseases (OMIM, Orphanet and DECIPHER) and other les 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.
The project of replacing the Norwegian requisition form led to the need for high exibility 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 technologies (Sequoia, HPO ontology) and demonstrated how these can be used to quickly navigate large knowledge sources. We have also applied the use of semantic technology to the task of creating suggestions for pediatricians using the HPO ontology, including di erent 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 characteristics to the geneticists. The next step is to validate the software with formal user testing, including iterative usability testing with pediatricians. 6
This work was done as part of the BIGMED project, funded by the Norwegian Research Council, Project No. 259055. We would like to thank the project members, and especially Yngve Sejersted and Tony Handstad at Oslo University Hospital for invaluable input on rare diseases and genetic testing.