Transforming Health Information Technology with a Knowledge Graph – Christopher Wixon


– Good afternoon everybody. My name is Chris Wixon. It’s a pleasure for me to be here today and share with you my experience with the creation of a knowledge graph for the healthcare industry. In full disclosure, unlike many of the accomplished data
scientists that are here today, I’m merely a practicing vascular surgeon. Next slide. I’ve been in practice for
approximately 20 years and during that time,
I’ve had the good fortune of caring for numerous patients with both life- and
limb-threatening problem. It’s truly gratifying work. I say this as I want to
emphasize the magnitude of the decision that I made
approximately four years ago. I contemplated quitting
the practice of medicine. Next slide. Like many other physicians
around the country, I was tired and angry. It was a classic case of burn out. Next slide. But before quitting, I asked
myself the obvious questions. Why was I so unhappy? After all, I had amazing
tools at my disposal, tools that allowed me to diagnose
problems at an early stage and then treat those problems with increasingly minimally
invasive techniques. Next slide. Ladies and gentlemen, the Electronic Health Record
is not one of those tools. At first, it seemed practical. Who would argue with a process that advocated legible documentation, electronic information sharing, and aggregate decision support? But soon after, next slide. But soon after implementation came the unintended consequences. As it turns out, electronic data entry is loathsome, soul-crushing work. It causes disruption to the
patient-physician interaction and is the proximate cause of widespread physician dissatisfaction. All the while, the promise
of improved outcomes and reduced health care
costs have remained elusive. Ironically, it was my discontent
with the current system that allowed me to pursue the solution that you’ll hear about today. Next slide. Early on, I spent time
developing customized templates that fit the new electronic format. Next slide. But no matter how much time I spent, the system remained
confusing, inefficient, and failed to adequately capture the essence of the patient’s illness. I didn’t realize it at the time, but these provided my formative
lessons in data modeling. Now, before I get too far down on the Electronic Health Record vendors, I’d like to say it’s not
necessarily their fault. As Henry Ford once famously said, “If I’d asked people what they had wanted, “they would have asked for faster horses.” Similarly, in an effort not to disrupt the physician workflows, designers of current
systems mimicked workflows around traditional paper medical records. That is to say, they were designed to simply be faster horses. It’s precisely what the
medical industry asked for, but not what they needed. I thought there must be a better way. Here is the key concept. Next slide. Here’s the key concept. Rather than documenting a patient history which contained a variety of data points, why not create data points which accurately reflected
the patient’s history? For me this was an epiphany. Next slide. Now it’s true that
healthcare data are complex. They exist in multiple locations, they’re structured and unstructured, they have inconsistent definitions, and are constantly changing
due to regulatory bodies. Next slide. Here are a few of the most commonly used terminology system by
the healthcare industry. Such systems are integral
to health informatic systems as they support the representation of detailed clinical concepts
in a computable manner. But on their own, the
terminology does nothing. They are only a single component needed for the solution for an
effective medical record. To benefit from a terminology, it must be implemented and used as part of an integral part of the application. Next slide. So what if we did just that? What if we used the patient’s problem as the core of our system? If we could pre-coordinate
medical knowledge in a clinically relevant manner, we could then enable
documentation through a process of simply semantically
navigating the graph. Next slide. I spent a lot of time on the white board developing convoluted models that looked something like this. Honestly, I was lost in the data and it was pretty messy stuff. I had to remind myself that the graph was being built to accomplish a particular case. In my case, to document a medical history. As such, the underlying schema needed to be purpose-driven
to facilitate usability. It also needed to deliver consistency and efficiency to the user. Next slide. After spending a great deal
of time on the problem, what emerged was a concept
model, or a meta model, that represented clinical concepts in the universal and economical matter. The key concept here is
the use of attribute nodes which correspond to various components of the Electronic Health Record. As such, in as such, serve
as a pointer function to tell the system how
a particular resource should be used in a particular
medical application. While the model appears
to be relatively simple, we found it to be incredibly expressive. Next slide. I think the best way to show the model is demonstrated through an example which demonstrates the relationships between clinical concepts. Let’s say we wish to
associate a medical diagnosis, say carpal tunnel syndrome, with a concept called hand weakness. We first create a direct
relationship between the two nodes, and then we use the attribute symptom, which describes the relationship
between the concepts. I should note that since our
resource nodes in the model are bound by this nomad ontology, all superclass concepts are
inherited by the resource node. We can talk about this later if anybody’s interested in this. Next slide. Another thing that I
really like about the model as it permits nodes that do
not contain explicit content, but rather allow the graph
to recommend data to the user that’s not explicitly entailed. For example, as part of a patient plan for the same diagnosis,
carpal tunnel syndrome, the physician wishes to make a referral to an orthopedic surgeon. Instead of creating explicit relationships between the tens of thousands
of orthopedic surgeons, we’re able to launch a node which references an APOC spatial query to locate all the physicians with the label orthopedic surgeon and having the criteria of sharing the location with the user. Obviously, the next step would be to include provider networks as part of the recommendation engine. Also, since this data that is
captured is fully structured, we can delegate the responsibility of processing the patient
referral to the computer. We can do the same thing
with prescription medicine, scheduled tests, and procedure. By making use of the APOC spatial query, we can look for pharmacies,
testing centers, hospitals which share a
geolocation with the patient. Next slide. Let’s go to the next slide. Before we get too far into
examples of the graph in action, I wanna spend a very brief moment to discuss ranking functions, because it’s important when you’re creating the knowledge graph. It’s something we
actually hadn’t thought of when we first developed the graph. Imagine we used the graph
to perform a faceted search on the terms metacarpal fracture. Next slide. Obviously, if alphabetical order does not make sense to the user, index being the first term
on the returned payload really doesn’t make sense, so sibling concept nodes
need to be presented in a contextually orderly manner and in the healthcare sector, concepts are more likely
to be ranked by size, severity, anatomic site, or
perhaps frequency of use. This is something that a domain expert will need to provide
when curating the graph. Next slide. So even if we can represent concepts in a clinically relevant,
economical, and orderly manner, the obvious questions arise. Can we truly map the
entire human condition? And if that’s possible, would the model be too
complex to be useful? Next slide. Obviously, to build such a tool, you’re gonna need a domain expert, and in the healthcare industry, you’re gonna need a team of them. The challenge is that these people tend to be in short supply, and they tend to be very busy people. Next slide. So where are we today? Today we built a graph that contains approximately 1.5 million
clinical concepts, and those clinical concepts are connected by about five million relationships. The graph contains the bulk of information for the fields of general
medicine, cardiovascular medicine, orthopedics, neurology, renal
medicine, and soft tissue, and we’re expanding the
graph nearly every day. Next slide. One of the things I think is really great about a knowledge graph is that it provides means for an expert physician like the gray-haired physician
in the upper left-hand corner to transfer knowledge to
a less-experienced user. Often, that’s the case in medicine. A doctor may see a patient that does not fall strictly
within their domain. The data encoded in the
graph can assist the user by providing lists of
potentially appropriate diagnostic or therapeutic decisions. Next slide. Okay, so we finally arrive
at the fun part of the talk. I brought a couple examples to
show you how this might work. Let’s say the user is
an orthopedic surgeon and he’s away from his office, perhaps he’s in the operating room. And for billing purposes, he needs the diagnosis code
associated with a broken leg. You might be surprised to learn that there are approximately
3,000 ICD-10 codes associated with this injury. One method is to go to a reference book that looks a lot like the yellow pages, and look the code up. It’s a tedious process. And if you hit the click button, I’ll show you how this works. For this use case, we designed
a smart phone application around the data contained in the graph. The data would first choose the patient, and then drive through the decision tree in order to get to the appropriate code. It’s hard to see in this potential thing, but they just drill through the code using very short numbers
of nodes to choose from in order to get to an actionable node associated with the particular entity. And there you have it. To provide context to the user, previously selected nodes
remain visible on the interface, and since this portion of the graph is arranged in an acyclic manner, if the user finds himself down
the wrong branch of the tree, it’s easy to go back up and explore a different
branch without getting lost. As an alternative, the app also supports a faceted keyword search method. Next is a very preliminary iteration which demonstrates how a user
would interact with the graph to document an entire patient visit. We purposely tried to create
an efficient user interface that is devoid of extraneous information. Context should come from the data itself, not from the interface. As I noted earlier, the
meta model of attributes corresponds to typical components of the physician encounter, such as history or present illness, physical examination,
review of systems, and plan. Each of those have
children which correspond to items in column one
as you see on the left. If you hit play now. So I’ll show you how you can go. This is a particular, the
diagnosis that you see in the blue bar on the top is a diagnosis of carotid stenosis, so when we ask the user to document, so that’s just showing
the different categories throughout the Electronic Health Record, and we go back to history
or present illness, and we ask what particular symptoms, it will start delivering
disease-specific symptoms to the user and they can
document whether that symptom is there in the affirmative
or the negative. The idea is to allow the
system to participate in the medical history taking
at the point of service and without being mentally
distracting to the user. In the bottom pane,
it’s hard to see there, you can see the history is documented concurrent to the navigation. And next slide. Upon completion, the system generates both human and machine
representations of the data, and the encounter is
immediately interoperable via a fire-compliant API. One more click. Another benefit of the
graph is that it can be used to store the clinical
information that was captured. Storing the information in a graph format would enable the array of graph algorithms to look for unrecognized
patterns which exist in the data. Perhaps at next year’s meeting, I’ll be able to bring that
back to show that to you. And next slide. I’d like to conclude by stating that I was fortunate enough
to emerge from burn out before throwing in the towel. Unfortunately, we continue to lose a number of good physicians
due to this process. And if we truly hope to
modernize our healthcare system, through improved outcomes
and reduced costs, we must acknowledge that healthcare is a data-dependent industry. Things like machine learning
and value-based healthcare will depend on concepts being represented in a reliable, a complete,
and a computable format. Last slide. Perhaps the medical knowledge graph can provide the necessary panacea. The knowledge graph offers
significant advantages over traditional symptoms, one of which is not listed there, it is the speed at which
the transactions occur. Latency is a very annoying process as you’re going through an
Electronic Health Record, the time between clicks
and the graph database is probably the fastest
platform out there. In addition, the graph participates in the medical encounter, and keeps the user focused
at the problem at hand. It enables the use of lightweight devices, such as a tablet, at the point of service. It enables less-experienced clinicians to function at the top
of their credentials. It provides a method of
storing clinical information suitable for pattern
recognition algorithms, and it can facilitate the delegation of tasks to the computer, such as scheduling and prescribing. And the last slide. Thank you very much for your attention, and I’ll be happy to answer any questions in the corridor afterward. Thank you. (audience applauding)

Leave a Reply