A Clinical Decision Support System Built With a Knowledge Graph

Daniel Crowe
Feb 16 · 13 min read

Using Open Source technologies to Improve Doctor-Patient Engagement

Debrief from a Grakn Community talk — featuring Alessia Basadonne, executive PHD candidate from University of Pavia and Medas Italy. This talk was delivered live at Grakn Cosmos 2020 in London, UK.

What’s the Problem these Systems Help to Solve?

How long does a patient spend with a doctor, on average?

With the exception of countries that self-report, the average was around 9 minutes per encounter. Alessia notes that after speaking with doctors and nurses, the reality is closer to 5 minutes. Now imagine what needs to be accomplished by the doctor in those 5 minutes:

  • Recall all of their personal medical experience
  • Provide diagnosis, treatment or behaviour recommendation to the patient

What’s the Solution?

A Clinical Decision Support System provides the doctor with a tool that eases their work, increases the value of the short time spent in the room with an individual, and ensures that the full context is available to the doctor.

Expert System as a CDSS

A system that manages and reasons over such a breadth of information such as: regional regulatory documents, situational recommendations, and patient data; starts to sound like an expert system.

  • Reasoning engine — reasoning across the knowledge base to provide recommendations based on scenarios
  • Interface — a user-facing platform to enable access and querying

What Work has Been Done Already?

in bringing expert systems to the medical decision domain…

How are Rules Used in Past and Current Systems?

Take a look at the below production rule from a 1970s system — you’ll notice that the rule is made up of a series of AND statements in the if clause, and concludes with THEN diagnosis =. We can imagine that using these rules can get fairly complex and messy. The CDSS currently in production in Italy, Alessia notes, is using rules like this. Leaving a lot of room for development.

Introducing SOPHIA

  • VPPower — a reporting system in OBGYN
  • MeView — a patient portal
  • Alert — when the recommendation suggests a behaviour
  • Tailored Recommendation

What’s the Stack Inside SOPHIA?

Traditionally, or rather for most engineers looking to build such an expert system using a knowledge graph and some NLP output, would require a host of technologies and languages from the semantic web. Alessia didn’t go down that path — choosing to use Grakn as the database, and its query language Graql, for its simplicity and expressiveness. Before we get there however, let’s take a look at the pieces needed to build a clinical decision support system or personal care agent.

Building SOPHIA

Now that we have a bit of context of where these systems have come from, and the components needed; let’s go through a step by step guide to building a Knowledge Graph based Clinical Decision Support System.

  • Tokenisation — able to extract single tokens from a sentence
  • Normalisation (Lemma) — able to understand similar or like words
  • Part-of-speech — able to extract parts of speech within a sentence
  • Shallow parsing — able to take those parts and link them with higher order groups (noun groups or phrases, verb groups, etc)
  • Entity recognition — able to extract named entities in unstructured text and classify them into defined categories, this is one of the most well loved components
"disease-disorder-mention": {
"start: 2325",
"end: 2334",
"";polarity: 1",
"[codingScheme: SNOMEDCT_US, code: 1008369006, cui: C0027651, tui: T191]"
"start: 3732",
"end: 3741",
"polarity: 1",
"[codingScheme: SNOMEDCT_US, code: 68453008, cui: C0007097, tui: T191J]"
"signs-symptom-mention": {
"TEST": [
"start: 95",
"end: 99",
"polarity: 1",
"anatomical-site-mention": {
"start: 2453",
"end: 2459",
"polarity: 1",
"UTERO": [
"start: 5652",
"end: 5657",
"polarity: 1",
"SKIN": [
"start: 2437",
"end: 2441",
"polarity: 1",

The last step is modelling the ontology, and this part is really simple…

In order to map all the data together, coming in from SOPHIA’s NLP pipeline, you need to model the data against Grakn’s knowledge model.

definemedical-entity sub entity,
owns start,
owns end,
owns polarity,
owns [attribute-name],
plays ctakes-named-entity-recognition:minded-token;
token sub entity,
plays [relation-name]:[role-name];
start sub attribute,
value: string;
end sub attribute,
value string;
polarity sub attribute,
value string;
ctakes-named-entity-recognition sub relation,
relates mined-token,
relates [role-name];
anatomical-site-mention sub medical-entity;medication-mention sub medical-entity;disease-disorder-mention sub medical-entity;date-annotation sub medical-entity;drug change status annotation sub medical-entity;fraction-strength-annotation sub medical-entity;measurement-annotation sub medical-entity;strength-annotation sub medical-entity;frequency-unit-annotation sub medical-entity;sign-symptom-mention sub medical-entity;

SOPHIA in Practice

To put all of this into perspective, Alessia shared a hypothetical real world scenario where a doctor is able to make use of a CDSS.

Challenges Faced Along the Way

Ambiguous Entities

  • Events Probably Not So Rare: W22.01walked into wall
  • That Should Never Happen: V97.33sucked into jet engine


Creators of TypeDB and TypeQL